Michael,

We have been working on a unified mechanism for Inte= r Layer Communication (ILC) and Simplified Congestion Control (SCC) for all= apps to use.

From looking at your draft charter, I am not sure that this fits into your group. Will you be h= aving a meeting in Vancouver to discuss? Did I miss that email?

Thanks,

Na= lini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestac= k.com

From: Michael Welzl <michawe@ifi.uio.no>
To: Matt Mathis <mattmathis@google.com> =
Cc: transport-services= @ifi.uio.no; tsv-area@ietf.org
S= ent: Wednesday, October 9, 2013 2:31 AM
Subject: Re: Call for participation: Transport Services<= br>

=0A

Hi,

I'll start with this:

Your broadcast mess= age should have included "Please discuss on xxxx list."

Apologies! The best I = can do is say it now: please discuss on the transport-services@ifi.uio.no list (in = cc); subscription info: https://sites.goo= gle.com/site/transportprotocolservices/

On 8. okt. 2013, at 18:15, Matt Mathis wrote:
I'm sorry if I haven't been paying attention, but wh= at do you mean by "the topic of transport services"?

Sever= al things come to mind:
- please deliver my data
=0A
- y/n= reliable delivery
- y/n out-of-order delivery
- = y/n fast connect, w/ or w/o crypto protection
- optimize for min = latency vs optimize for max throughput
- weighted congestion cont= rol for fine tuning priorities
=0A=0A
- y/n multiple paths o= r endpoints
- y/n "nat compatible"
- y/n for event noti= fication (up/down etc)
- etc
<= br>
I'd include many but not all of the things above. A part of t= he exercise of working towards a BOF is to agree on how to decide which thi= ngs would and wouldn't be included in a list of transport services, and a f= irst stab at the approach for arriving at a list is included in our initial= charter proposal:
https://sites.google.com/site/transportprotocolservices/home= /charter-proposal-before-bof
(the steps 1, 2, 3).
<= br>
If this sounds too abstract, I can go through your list above= case-by-case using the method described there, leading to "in", "probably = in, but represented in another way", "out" decisions for every item in the list I think - but right now I'll refrain = from doing that to avoid making this email unnecessarily long.

In varying= degrees we know how to do most of these in both TCP and SCPT. The tr= ick to providing them as "services" is to unbundle the (sub)layers.

Yes.

If you mean to design a API, I think= you will find that the IETF has a lot of trouble with stuff that is not vi= sible on the wire, and has repeatedly failed to converge on such issues.

I mean to design services t= hat would be exposed by an API, and describe example API implementations.
(which is a politician's way of saying "yes, I want to design an A= PI", I guess :-) )

About what's visible on the wire: imagine that, instead of having the transport mechani= sms that applications want embedded in the applications, we'd have a transp= ort system underneath an API that we could just ask for a certain service i= nstead of only requesting "TCP" or "UDP". Then clients would like to tell s= ervers what kinds of services they'd like to have or which services they co= uld accept. This signaling would have to specify a transport service (so th= ere you have something on the wire) - but without having a standardized lis= t of transport services, all a client can ever do is to signal services tha= t it *knows* to be available on the other side. Without a standardized list= , the only way to know what's available is if it's the same application - e= .g. Skype talking to Skype. So this is how we're stuck with a situation whe= re every application that needs a bit more than TCP's behavior from the net= work has its own UDP-based transport solution built in. I think the first step towards breaking this up is to agree on services and define the= m (and write the code, which some folks involved in this are doing).
<= div>
Cheers,
Michael

--36908767-1009987606-1381407033=:31849-- From michawe@ifi.uio.no Thu Oct 10 05:54:34 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6962011E8158 for ; Thu, 10 Oct 2013 05:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.672 X-Spam-Level: X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_PROLOSTOCK_SYM3=1.63, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTlZteG3syej for ; Thu, 10 Oct 2013 05:54:29 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 5243811E8141 for ; Thu, 10 Oct 2013 05:54:27 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VUFky-0001Gi-5A; Thu, 10 Oct 2013 14:54:20 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUFkx-0001Px-7O; Thu, 10 Oct 2013 14:54:20 +0200 Subject: Plan for Vancouver Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2080E1AF-0AB6-47C4-B2AB-BF6E8109306B" From: Michael Welzl In-Reply-To: <1381407033.31849.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Thu, 10 Oct 2013 14:54:17 +0200 Message-Id: References: <29E74FC8-C676-4685-98E5-22C5579C3D9B@ifi.uio.no>

<1381407033.31849.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 13 sum msgs/h 8 total rcpts 8375 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.502, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B29041B914454F4FAD02221B586F45B7822D6F22 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 3275 max/h 16 blacklist 0 greylist 1 ratelimit 0 Cc: "transport-services@ifi.uio.no" , "tsv-area@ietf.org" , Matt Mathis X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:54:34 -0000 --Apple-Mail=_2080E1AF-0AB6-47C4-B2AB-BF6E8109306B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I updated the subject... I hadn't made a plan for meeting yet; given = the many collisions people usually have in the evenings of the IETF = week, the relatively low priority this will have to many, and the = unknown number of people interested + on site, I suggest the following = procedure: Many of us will be at TCPM on Monday morning, which ends at 11:30; I = will then stand at the IETF reception desk on Monday from 11:40 to = 12:00, collecting people. If you show up in this time frame, you become = part of a group that goes off to have lunch in the hotel together at = 12:00, and will chat until up to 14:30 (the end of the next time slot, = which doesn't contain anything related to TSV). If I find myself in a = crowd of hundreds of people standing there, all craving for food on = Monday lunch time, we'll use this chance to agree on a day and time for = an evening meeting in a bar somewhere (making it a "real" bar BOF, with = beer and stuff! woo hoo!), and I'll figure out a place and announce it = on the transport-services list. Again, the short version: Monday 11:40-12:00, reception desk. Be there = and see what happens. Cheers, Michael On 10. okt. 2013, at 14:10, Nalini Elkins wrote: > Michael, >=20 > We have been working on a unified mechanism for Inter Layer = Communication (ILC) and Simplified Congestion Control (SCC) for all apps = to use. >=20 > =46rom looking at your draft charter, I am not sure that this fits = into your group. Will you be having a meeting in Vancouver to discuss? = Did I miss that email? > =20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 > From: Michael Welzl > To: Matt Mathis =20 > Cc: transport-services@ifi.uio.no; tsv-area@ietf.org=20 > Sent: Wednesday, October 9, 2013 2:31 AM > Subject: Re: Call for participation: Transport Services >=20 > Hi, >=20 > I'll start with this: >=20 >> Your broadcast message should have included "Please discuss on xxxx = list." >=20 > Apologies! The best I can do is say it now: please discuss on the = transport-services@ifi.uio.no list (in cc); subscription info: = https://sites.google.com/site/transportprotocolservices/ >=20 >=20 > On 8. okt. 2013, at 18:15, Matt Mathis wrote: >=20 >> I'm sorry if I haven't been paying attention, but what do you mean by = "the topic of transport services"? >>=20 >> Several things come to mind: >> - please deliver my data >> - y/n reliable delivery=20 >> - y/n out-of-order delivery >> - y/n fast connect, w/ or w/o crypto protection >> - optimize for min latency vs optimize for max throughput >> - weighted congestion control for fine tuning priorities=20 >> - y/n multiple paths or endpoints >> - y/n "nat compatible" >> - y/n for event notification (up/down etc) >> - etc >=20 > I'd include many but not all of the things above. A part of the = exercise of working towards a BOF is to agree on how to decide which = things would and wouldn't be included in a list of transport services, = and a first stab at the approach for arriving at a list is included in = our initial charter proposal: > = https://sites.google.com/site/transportprotocolservices/home/charter-propo= sal-before-bof > (the steps 1, 2, 3). >=20 > If this sounds too abstract, I can go through your list above = case-by-case using the method described there, leading to "in", = "probably in, but represented in another way", "out" decisions for every = item in the list I think - but right now I'll refrain from doing that to = avoid making this email unnecessarily long. >=20 >=20 >> In varying degrees we know how to do most of these in both TCP and = SCPT. The trick to providing them as "services" is to unbundle the = (sub)layers. >=20 > Yes. >=20 >=20 >> If you mean to design a API, I think you will find that the IETF has = a lot of trouble with stuff that is not visible on the wire, and has = repeatedly failed to converge on such issues. >=20 > I mean to design services that would be exposed by an API, and = describe example API implementations. > (which is a politician's way of saying "yes, I want to design an API", = I guess :-) ) >=20 > About what's visible on the wire: imagine that, instead of having the = transport mechanisms that applications want embedded in the = applications, we'd have a transport system underneath an API that we = could just ask for a certain service instead of only requesting "TCP" or = "UDP". Then clients would like to tell servers what kinds of services = they'd like to have or which services they could accept. This signaling = would have to specify a transport service (so there you have something = on the wire) - but without having a standardized list of transport = services, all a client can ever do is to signal services that it *knows* = to be available on the other side. Without a standardized list, the only = way to know what's available is if it's the same application - e.g. = Skype talking to Skype. So this is how we're stuck with a situation = where every application that needs a bit more than TCP's behavior from = the network has its own UDP-based transport solution built in. I think = the first step towards breaking this up is to agree on services and = define them (and write the code, which some folks involved in this are = doing). >=20 > Cheers, > Michael >=20 >=20 >=20 --Apple-Mail=_2080E1AF-0AB6-47C4-B2AB-BF6E8109306B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Again, the = short version: Monday 11:40-12:00, reception desk. Be there and see what = happens.

Cheers,

Michael=

On 10. = okt. 2013, at 14:10, Nalini Elkins wrote:

Michael,

We have been = working on a unified mechanism for Inter Layer Communication (ILC) and = Simplified Congestion Control (SCC) for all apps to = use.

=46rom looking at your draft charter, I am not sure that this fits into your group. Will you = be having a meeting in Vancouver to discuss? Did I miss that = email?

Thanks,

=
Nalini Elkins
Inside Products, Inc.
(831) = 659-8360
www.insidethestack.com

= From: Michael Welzl <michawe@ifi.uio.no>
= To: Matt Mathis <mattmathis@google.com> =
Cc: transport-services@ifi.uio.n= o; tsv-area@ietf.org
= Sent: Wednesday, = October 9, 2013 2:31 AM
Subject: Re: Call for participation: Transport = Services

Hi,

I'll start with = this:

Your broadcast message should have included "Please = discuss on xxxx list."

Apologies! The best I can do is = say it now: please discuss on the transport-services@ifi.uio.n= o list (in cc); subscription info: https://= sites.google.com/site/transportprotocolservices/

<= div>
On 8. okt. 2013, at 18:15, Matt = Mathis wrote:

I'm sorry if I haven't been paying = attention, but what do you mean by "the topic of transport = services"?

Several things come to mind:
- = please deliver my data

- y/n reliable delivery
- y/n out-of-order = delivery
- y/n fast connect, w/ or w/o crypto = protection
- optimize for min latency vs optimize for max = throughput
- weighted congestion control for fine tuning = priorities

- y/n multiple paths or endpoints
- y/n "nat = compatible"
- y/n for event notification (up/down = etc)
- = etc

I'd include many = but not all of the things above. A part of the exercise of working = towards a BOF is to agree on how to decide which things would and = wouldn't be included in a list of transport services, and a first stab = at the approach for arriving at a list is included in our initial = charter proposal:
https://sites.google.com/site/transportprotocolser= vices/home/charter-proposal-before-bof
(the steps 1, 2, = 3).

If this sounds too abstract, I can go = through your list above case-by-case using the method described there, = leading to "in", "probably in, but represented in another way", "out" decisions for every item in the list I think - but right now I'll = refrain from doing that to avoid making this email unnecessarily = long.

In varying degrees we know how to do most of these = in both TCP and SCPT. The trick to providing them as "services" is = to unbundle the = (sub)layers.

Yes.
<= br>
If you mean = to design a API, I think you will find that the IETF has a lot of = trouble with stuff that is not visible on the wire, and has repeatedly = failed to converge on such = issues.

I mean to = design services that would be exposed by an API, and describe example = API implementations.
(which is a politician's way of saying = "yes, I want to design an API", I guess :-) = )

About what's visible on the wire: imagine that, instead of having the transport = mechanisms that applications want embedded in the applications, we'd = have a transport system underneath an API that we could just ask for a = certain service instead of only requesting "TCP" or "UDP". Then clients = would like to tell servers what kinds of services they'd like to have or = which services they could accept. This signaling would have to specify a = transport service (so there you have something on the wire) - but = without having a standardized list of transport services, all a client = can ever do is to signal services that it *knows* to be available on the = other side. Without a standardized list, the only way to know what's = available is if it's the same application - e.g. Skype talking to Skype. = So this is how we're stuck with a situation where every application that = needs a bit more than TCP's behavior from the network has its own = UDP-based transport solution built in. I think the first step towards breaking this up is to agree on services and define = them (and write the code, which some folks involved in this are = doing).

Cheers,
Michael

<= /div>

=

= --Apple-Mail=_2080E1AF-0AB6-47C4-B2AB-BF6E8109306B-- From nalini.elkins@insidethestack.com Thu Oct 10 06:11:22 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1DB11E8165 for ; Thu, 10 Oct 2013 06:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyWMuJQlyqhl for ; Thu, 10 Oct 2013 06:11:15 -0700 (PDT) Received: from nm4-vm7.access.bullet.mail.gq1.yahoo.com (nm4-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4010211E80E3 for ; Thu, 10 Oct 2013 06:11:10 -0700 (PDT) Received: from [216.39.60.171] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Oct 2013 13:09:57 -0000 Received: from [216.39.60.163] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Oct 2013 13:09:57 -0000 Received: from [127.0.0.1] by omp1029.access.mail.gq1.yahoo.com with NNFMP; 10 Oct 2013 13:09:57 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 366985.28216.bm@omp1029.access.mail.gq1.yahoo.com Received: (qmail 69412 invoked by uid 60001); 10 Oct 2013 13:09:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381410596; bh=P+e3k7+43pnsKUnFqFRGYiC6vhAVJy5wiZGHd/dJl5Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qUCmGqZeXGB3Zj4bu8oA2vDOre87MnulsXHh6OWN8+7ih40MSJjB4eeFXPw6UR4Zi6lrB6iYfN5Rr7Ij7W81DHwH+W031Q8ve2vZUfHUvZMu+9zJOJbJsGlU+MkHjC1cdWElS/eTOw65B+V/k82bFb73FaGKYnYiSxeaEEyWNCg= X-YMail-OSG: CY71cJkVM1mc7_Su_UO5B52betxM8Vgm9OwopR72Y9kR4V. hLHwlSs8fMNRk_V9b3l0dgPsTKFUImAIOs2U7D0kvugUwcdrB9Nq2cgi6AJu stOoKqtde1ckHP0rjyoUMsVSKknIL7fWqxA3lWzydqirN09REZUHhIo7Y._U Ozip12a6RgO4iMa_O2Uh4rwd5MsjHrsOAOiX7jzuGQZ.RLg0T_NUII3i0ndw A8Rly1lFppKOPIN7hEk1ip_rfgGDszfScctbBaJDZtUewmTTMDTnid8iz8zm IOsjKuFjruuhI_Ck2IUDHm1kzn_Lwl96E0P2awlitE33ImhrqW5OSssLXlgM Zk6UIfFobgMZexA1n4TwY4hHxN8bm13rHEKqS8QbF4EtQLEYSSRydbmtiCI8 ZSt_bu7t7ykmSlJv8qMu8ioKCHZEZ3udhndeFoJWyxcWO9E6Kk8_0tcDocjp QcNVp_ng7W2UdYWRXuFGtvp4IpNr9BY433KgRtB25y_wA4dvT7WaJf6R60_5 VPP8LAmEaKtKtN6aHqRuuNJVI8pzrs._Ynblkz4SLBNe07JCd9xhlNCp4lrc IJkTvaLNyCQ8n50_v2iXP2FeE5kRVOr6va7oDBtC16Q.aJw0Ic0vtk5MWHeT CsqP3wg.X.owb1Ya7nRYmujzWCW2joaPkQfXC5MfnCqF1xXMGzAUqVEopojm 2e3geUd6t5NsVyXGiCyw3i1LyuetUgEvD98PYB5FtJcUhdnFONzKbPdIDKT7 FVACwdSXl8WBjmHatLkT4F826bht9wzaabjhHgaCdpnyQnXvvEuRIXwaYYJM - Received: from [24.184.255.124] by web2805.biz.mail.ne1.yahoo.com via HTTP; Thu, 10 Oct 2013 06:09:56 PDT X-Rocket-MIMEInfo: 002.001, V2lsbCBiZSB0aGVyZSBmb3Igc3VyZSEKwqAKVGhhbmtzLAoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogTWljaGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vPgpUbzogTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.IApDYzogTWF0dCBNYXRoaXMgPG1hdHRtYXRoaXNAZ29vZ2xlLmNvbT47ICJ0cmFuc3ABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <29E74FC8-C676-4685-98E5-22C5579C3D9B@ifi.uio.no>

<1381407033.31849.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Message-ID: <1381410596.7966.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Thu, 10 Oct 2013 06:09:56 -0700 (PDT) From: Nalini Elkins Subject: Re: Plan for Vancouver To: Michael Welzl In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1242494557-1381410596=:7966" Cc: "transport-services@ifi.uio.no" , "tsv-area@ietf.org" , Matt Mathis X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 13:11:22 -0000 --1619178251-1242494557-1381410596=:7966 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Will be there for sure!=0A=A0=0AThanks,=0A=0ANalini Elkins=0AInside Product= s, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______________= __________________=0A From: Michael Welzl =0ATo: Nalini= Elkins =0ACc: Matt Mathis ; "transport-services@ifi.uio.no" = ; "tsv-area@ietf.org" =0ASent: Thursday, October 10, 20= 13 5:54 AM=0ASubject: Plan for Vancouver=0A =0A=0A=0AHi,=0A=0AI updated the= subject... =A0 I hadn't made a plan for meeting yet; given the many collis= ions people usually have in the evenings of the IETF week, the relatively l= ow priority this will have to many, and the unknown number of people intere= sted + on site, I suggest the following procedure:=0A=0AMany of us will be = at TCPM on Monday morning, which ends at 11:30; I will then stand at the IE= TF reception desk on Monday from 11:40 to 12:00, collecting people. If you = show up in this time frame, you become part of a group that goes off to hav= e lunch in the hotel together at 12:00, and will chat until up to 14:30 (th= e end of the next time slot, which doesn't contain anything related to TSV)= .=A0If I find myself in a crowd of hundreds of people standing there, all c= raving for food on Monday lunch time, we'll use this chance to agree on a d= ay and time for an evening meeting in a bar somewhere (making it a "real" b= ar BOF, with beer and stuff! woo hoo!), and I'll figure out a place and ann= ounce it on the transport-services list.=0A=0AAgain, the short version: Mon= day 11:40-12:00, reception desk. Be there and see what happens.=0A=0A=0AChe= ers,=0AMichael=0A=0A=0A=0AOn 10. okt. 2013, at 14:10, Nalini Elkins wrote:= =0A=0AMichael,=0A>=0A>=0A>We have been working on a unified mechanism for I= nter Layer Communication (ILC) and Simplified Congestion Control (SCC) for = all apps to use.=0A>=0A>=0A>From looking at your draft charter, I am not su= re that this fits into your group. =A0Will you be having a meeting in Vanco= uver to discuss? =A0Did I miss that email?=0A>=A0=0A>Thanks,=0A>=0A>=0A>Nal= ini Elkins=0A>Inside Products, Inc.=0A>(831) 659-8360=0A>www.insidethestack= .com=0A>=0A>=0A>=0A>________________________________=0A> From: Michael Welz= l =0A>To: Matt Mathis =0A>Cc: t= ransport-services@ifi.uio.no; tsv-area@ietf.org =0A>Sent: Wednesday, Octobe= r 9, 2013 2:31 AM=0A>Subject: Re: Call for participation: Transport Service= s=0A> =0A>=0A>=0A>Hi,=0A>=0A>=0A>I'll start with this:=0A>=0A>=0A>Your broa= dcast message should have included "Please discuss on xxxx list."=0A>=0A>= =0A>Apologies! =A0The best I can do is say it now: please discuss on the=A0= transport-services@ifi.uio.no list (in cc); subscription info:=A0https://si= tes.google.com/site/transportprotocolservices/=0A>=0A>=0A>=0A>=0A>On 8. okt= . 2013, at 18:15, Matt Mathis wrote:=0A>=0A>I'm sorry if I haven't been pay= ing attention, but what do you mean by "the topic of transport services"?= =0A>>=0A>>=0A>>Several things come to mind:=0A>>=0A>>- please deliver my da= ta=0A>>- y/n reliable delivery=A0=0A>>- y/n out-of-order delivery=0A>>- y/n= fast connect, w/ or w/o crypto protection=0A>>- optimize for min latency v= s optimize for max throughput=0A>>- weighted congestion control for fine tu= ning priorities=A0=0A>>- y/n multiple paths or endpoints=0A>>- y/n "nat com= patible"=0A>>- y/n for event notification (up/down etc)=0A>>- etc=0A>=0A>= =0A>I'd include many but not all of the things above. A part of the exercis= e of working towards a BOF is to agree on how to decide which things would = and wouldn't be included in a list of transport services, and a first stab = at the approach for arriving at a list is included in our initial charter p= roposal:=0A>https://sites.google.com/site/transportprotocolservices/home/ch= arter-proposal-before-bof=0A>(the steps 1, 2, 3).=0A>=0A>=0A>If this sounds= too abstract, I can go through your list above case-by-case using the meth= od described there, leading to "in", "probably in, but represented in anoth= er way", "out" decisions for every item in the list I think - but right now= I'll refrain from doing that to avoid making this email unnecessarily long= .=0A>=0A>=0A>=0A>In varying degrees we know how to do most of these in both= TCP and SCPT. =A0The trick to providing them as "services" is to unbundle = the (sub)layers.=0A>=0A>Yes.=0A>=0A>=0A>=0A>If you mean to design a API, I = think you will find that the IETF has a lot of trouble with stuff that is n= ot visible on the wire, and has repeatedly failed to converge on such issue= s.=0A>=0A>=0A>I mean to design services that would be exposed by an API, an= d describe example API implementations.=0A>(which is a politician's way of = saying "yes, I want to design an API", I guess =A0 :-) =A0 )=0A>=0A>=0A>Abo= ut what's visible on the wire: imagine that, instead of having the transpor= t mechanisms that applications want embedded in the applications, we'd have= a transport system underneath an API that we could just ask for a certain = service instead of only requesting "TCP" or "UDP". Then clients would like = to tell servers what kinds of services they'd like to have or which service= s they could accept. This signaling would have to specify a transport servi= ce (so there you have something on the wire) - but without having a standar= dized list of transport services, all a client can ever do is to signal ser= vices that it *knows* to be available on the other side. Without a standard= ized list, the only way to know what's available is if it's the same applic= ation - e.g. Skype talking to Skype. So this is how we're stuck with a situ= ation where every application that needs a bit more than TCP's behavior fro= m the network has its own UDP-based transport solution built in. I think the first step towards breaking this up is to agree on services an= d define them (and write the code, which some folks involved in this are do= ing).=0A>=0A>=0A>Cheers,=0A>Michael=0A>=0A>=0A>=0A> --1619178251-1242494557-1381410596=:7966 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Will be there for sur= e!

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insid= ethestack.com

From: Michael Welzl <michawe@ifi.uio.no>
To: Nalini Elkins <nalini.elkins@in= sidethestack.com>
Cc: Matt Mathis <mattmathis@google.com>; "transport-services@ifi.uio.n= o" <transport-services@ifi.uio.no>; "tsv-area@ietf.org" <tsv-area@= ietf.org>
Sent: Thursday, Octo= ber 10, 2013 5:54 AM
Subject: Plan for Vancouver

=0A

Hi,

I updated th= e subject... I hadn't made a plan for meeting yet; given the many co= llisions people usually have in the evenings of the IETF week, the relative= ly low priority this will have to many, and the unknown number of people in= terested + on site, I suggest the following procedure:

=

Many of us will be at TCPM on Monday morning, which ends at 11:30; I w= ill then stand at the IETF reception desk on Monday from 11:40 to 12:00, co= llecting people. If you show up in this time frame, you become part of a gr= oup that goes off to have lunch in the hotel together at 12:00, and will ch= at until up to 14:30 (the end of the next time slot, which doesn't contain = anything related to TSV). If I find myself in a crowd of hundreds of p= eople standing there, all craving for food on Monday lunch time, we'll use = this chance to agree on a day and time for an evening meeting in a bar somewhere (making it a "real" bar BOF, with beer and stuff! woo hoo!), and= I'll figure out a place and announce it on the transport-services list.

Again, the short version: Monday 11:40-12:00, recept= ion desk. Be there and see what happens.

Cheers,
Michael

On 10. okt. 2013, at 14:10, Nalini Elkins wrote:
<= span>Michael,

We have been wor= king on a unified mechanism for Inter Layer Communication (ILC) and Simplif= ied Congestion Control (SCC) for all apps to use.

From looking at your draft=0A charter, I am not sure that this fi= ts into your group. Will you be having a meeting in Vancouver to disc= uss? Did I miss that email?

<= div>Thanks,

Nalini Elkins
Inside Products, Inc.=
(831) 659-8360
www.insidethestack.com

From: Michael Welzl <<= a rel=3D"nofollow" ymailto=3D"mailto:michawe@ifi.uio.no" target=3D"_blank" = href=3D"mailto:michawe@ifi.uio.no">michawe@ifi.uio.no>
To: Matt Mathis <mattmathis@google.com>
Cc: transport-services@ifi.uio.no; tsv-area@ietf.org
Sent: Wednesday, October 9, 2013 2:31 AM
= Subject: Re: Call for pa= rticipation: Transport Services

=0A
Hi,

I'll start with this:

Your broadcast message should have included "Plea= se discuss on xxxx list."

Apologies! The best I can do is say it now: please d= iscuss on the transport-services@ifi.uio.no list (in cc); subscription info: <= a rel=3D"nofollow" target=3D"_blank" href=3D"https://sites.google.com/site/= transportprotocolservices/">https://sites.google.com/site/transportprotocol= services/

On 8= . okt. 2013, at 18:15, Matt Mathis wrote:

I'm sor= ry if I haven't been paying attention, but what=0A do you mean by "the topi= c of transport services"?

Several things come to mind:
- please deliver my data
=0A
- y/n reliable delivery <= /div>
- y/n out-of-order delivery
- y/n fast connect, w/ or w= /o crypto protection
- optimize for min latency vs optimize for m= ax throughput
- weighted congestion control for fine tuning prior= ities
=0A=0A
- y/n multiple paths or endpoints
- y= /n "nat compatible"
- y/n for event notification (up/down etc)
- etc

I'd include= many but not all of the things above. A part of the exercise of working to= wards a BOF is to agree on how to decide which things would and wouldn't be= included in a list of transport services, and a first stab at the approach= for arriving at a list is included in our initial charter proposal:
<= div>https://si= tes.google.com/site/transportprotocolservices/home/charter-proposal-before-= bof
(the steps 1, 2, 3).

If this sou= nds too abstract, I can go through your list above case-by-case using the m= ethod described there, leading to "in", "probably in, but represented in an= other way", "out"=0A decisions for every item in the list I think - but rig= ht now I'll refrain from doing that to avoid making this email unnecessaril= y long.

=
In varying degrees we know how to do most of these in both TCP an= d SCPT. The trick to providing them as "services" is to unbundle the = (sub)layers.

Yes.

If you mean to d= esign a API, I think you will find that the IETF has a lot of trouble with = stuff that is not visible on the wire, and has repeatedly failed to converg= e on such issues.

I mean = to design services that would be exposed by an API, and describe example AP= I implementations.
(which is a politician's way of saying "yes, I= want to design an API", I guess :-) )

About what's=0A visible on the wire: imagine that, instead of having the= transport mechanisms that applications want embedded in the applications, = we'd have a transport system underneath an API that we could just ask for a= certain service instead of only requesting "TCP" or "UDP". Then clients wo= uld like to tell servers what kinds of services they'd like to have or whic= h services they could accept. This signaling would have to specify a transp= ort service (so there you have something on the wire) - but without having = a standardized list of transport services, all a client can ever do is to s= ignal services that it *knows* to be available on the other side. Without a= standardized list, the only way to know what's available is if it's the sa= me application - e.g. Skype talking to Skype. So this is how we're stuck wi= th a situation where every application that needs a bit more than TCP's beh= avior from the network has its own UDP-based transport solution built in. I= think the=0A first step towards breaking this up is to agree on services a= nd define them (and write the code, which some folks involved in this are d= oing).

Cheers,
Michael

--1619178251-1242494557-1381410596=:7966-- From scott.brim@gmail.com Thu Oct 10 10:55:46 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8AE21F9C7D; Thu, 10 Oct 2013 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02lRoMGVEVhW; Thu, 10 Oct 2013 10:55:41 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9B05911E8193; Thu, 10 Oct 2013 10:55:22 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h14so1365115eak.1 for ; Thu, 10 Oct 2013 10:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ed9vLKYbrdjgyJEH2Qnvd1tj3P7smQ1ODBN49on+tPA=; b=wCvDEypb+PEhue+Q7q8HlqhN1fyiIbuHskiXCyLrdP4u6mbJCag205iG04fHIcTop0 aMVPYTYcNlcJcoVN9bDKKcz/C7JvDtNwBYijKNgCTvdhZtvbBjz6sGfHVapPJtC/BtOm d7FFJLEiIYDRXfJQ6Ub/oAYvC9+NHCPIBXueCe3980Gs3aY93cgLB8lFVspQRsaWTxJI Mg78UPcYvOV4MUSjnYP5GIwkzzEDKgET8RKn07Kr/2Ty0aGY+1LBJjJ3xlNZu9ujm8So /wQ9cs3yDogJ4G+ZjuWk4fKSzhn+ak82wkOlXXGQoGrqt7cZ0hZD+6/XVEfPvdoxsURy b0Fg== MIME-Version: 1.0 X-Received: by 10.14.210.8 with SMTP id t8mr22100914eeo.39.1381427721782; Thu, 10 Oct 2013 10:55:21 -0700 (PDT) Received: by 10.14.205.7 with HTTP; Thu, 10 Oct 2013 10:55:21 -0700 (PDT) Received: by 10.14.205.7 with HTTP; Thu, 10 Oct 2013 10:55:21 -0700 (PDT) In-Reply-To: <003801cec408$32ea9560$98bfc020$@unizar.es> References: <003801cec408$32ea9560$98bfc020$@unizar.es> Date: Thu, 10 Oct 2013 13:55:21 -0400 Message-ID: Subject: Re: Community Neworks: any idea about them? From: Scott Brim To: jsaldana@unizar.es Content-Type: multipart/alternative; boundary=047d7b603fe2a3c9fa04e866b4e0 Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:55:47 -0000 --047d7b603fe2a3c9fa04e866b4e0 Content-Type: text/plain; charset=ISO-8859-1 For the USA you might find http://muninetworks.org interesting. --047d7b603fe2a3c9fa04e866b4e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the USA you might find http://muninetworks.org interesting.=A0
--047d7b603fe2a3c9fa04e866b4e0-- From l.wood@surrey.ac.uk Thu Oct 10 14:48:35 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180E821E80B9; Thu, 10 Oct 2013 14:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.831 X-Spam-Level: X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmxmD0HkUqbH; Thu, 10 Oct 2013 14:48:31 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2807521F8E51; Thu, 10 Oct 2013 14:48:23 -0700 (PDT) Received: from [85.158.136.51:16491] by server-7.bemta-5.messagelabs.com id CA/85-24315-6A027525; Thu, 10 Oct 2013 21:48:22 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-3.tower-49.messagelabs.com!1381441702!27182889!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29472 invoked from network); 10 Oct 2013 21:48:22 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-3.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 10 Oct 2013 21:48:22 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.148]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Thu, 10 Oct 2013 22:48:21 +0100 From: To: , Date: Thu, 10 Oct 2013 22:46:19 +0100 Subject: RE: [tcmtf] Community Neworks: any idea about them? Thread-Topic: [tcmtf] Community Neworks: any idea about them? Thread-Index: AQGsCYleI6d2ClbR0uwHsWWEfAsQMQE+g/hmAYGvmKkAwoWkeJoXBfzQgADVdn8= Message-ID: <290E20B455C66743BE178C5C84F12408374274D58A@EXMB01CMS.surrey.ac.uk> References: <003801cec408$32ea9560$98bfc020$@unizar.es> <000101cec41b$b116ddf0$134499d0$@unizar.es> , <001301cec598$f094d670$d1be8350$@unizar.es> In-Reply-To: <001301cec598$f094d670$d1be8350$@unizar.es> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcmtf@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:48:35 -0000 Webcam/chat is realtime. http://en.wikipedia.org/wiki/Niue The island of Niue has a similar free internet model, backhauled via a sat= ellite link. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf Of Jo= se Saldana [jsaldana@unizar.es] Sent: 10 October 2013 10:13 To: tsv-area@ietf.org Cc: tcmtf@ietf.org Subject: RE: [tcmtf] Community Neworks: any idea about them? Regarding Community Networks, I have found some information about their deployment in rural areas. The Council of a village shares an Internet connection with all the neighbors, and they get Internet for free. For example, see this small village (1400 people) called Alcalal=ED, in Alicant= e, Spain. http://www.alcalali.es/ver/137/informacion-general.html. The question is that, when they talk about the services, they say "Consulta de p=E1ginas web, descarga de correos, Facebook, Youtube, Yahoo, Hotmail, webcam, chats, etc." (web pages, e-mail, Facebook, Youtube, Yahoo, Hotmail, webcam, chats, etc.). Not a single real-time service is cited. This can be a very interesting use case for TCM-TF: a "bottleneck" (the Internet connection) shared by a number of people. If traffic gets optimized, perhaps they could also offer real-time services like VoIP. What do you think? This is working in Spain, but it can also be useful for developing countries or zones where network operators have not deployed an infrastructure yet. Thanks! Jose > -----Mensaje original----- > De: arjuna.sathiaseelan@gmail.com [mailto:arjuna.sathiaseelan@gmail.com] > En nombre de Arjuna Sathiaseelan > Enviado el: martes, 08 de octubre de 2013 23:43 > Para: jsaldana@unizar.es > CC: tcmtf@ietf.org; tsv-area@ietf.org > Asunto: Re: [tcmtf] Community Neworks: any idea about them? > > Hello Jose, > Any method that utilises the low bandwidth infrastructure more efficientl= y is > definitely useful. > > Just a digression: have you considered the use of UDP-lite for TCM-TF? > > Regards > Arjuna > > On 8 October 2013 12:44, Jose Saldana wrote: > > Hi, Arjuna, > > > > The idea of multipath TCP sounds interesting. It consists of "inverse > > multiplexing" with TCP. However, TCM-TF does "multiplexing" with UDP. > > > > What I was thinking is: can these scenarios also fit with TCM-TF? The > > idea is to compress small-packet flows (VoIP, online games) in order > > to save bandwidth, when a number of flows share a common path. We > have > > discarded the multiplexing of TCP, because the additional delay may > > modify the dynamics of TCP. > > > > TCM-TF combines header compression, multiplexing and tunneling, in > > order to aggregate a number of flows, when a low-bandwidth link is in > > the path. Thus, bandwidth can be saved and pps can be reduced, at the > > cost of processing power. > > > > Do you think this case can be found in these kind of networks? In the > > discussion of TCM-TF in Berlin this summer, some people from Africa > > were interested, since they think that low-bandwidth links have to be > > better used. > > > > Thanks! > > > > Jose > > > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre > >> de Arjuna Sathiaseelan Enviado el: martes, 08 de octubre de 2013 > >> 11:42 > >> Para: jsaldana@unizar.es > >> CC: tcmtf@ietf.org; tsv-area@ietf.org > >> Asunto: Re: [tcmtf] Community Neworks: any idea about them? > >> > >> Dear Jose, > >> I would like to take this opportunity to present some of the work > >> we are doing here at Cambridge - > >> > >> We are trying to solve the universal service problem in urban areas > >> (where people cannot afford to access the Internet) using existing > >> home broadband networks - home owners who have Internet > connections > >> share their Internet connection for free with those who dont have. > >> > >> We are currently doing deployments in a deprived area in Nottingham ( > >> see www.publicaccesswifi.org ) > >> > >> More on the LCDNet initiative is here: > >> http://www.cl.cam.ac.uk/~as2330/lcd/index.html > >> > >> There are interesting possibilities to do multi-path TCP between > > aggregating > >> multiple access points and we are exploring that option too. > >> > >> The TIER group in berkeley have done quite a lot of nice work with > > wireless > >> for developing countries: > >> tier.cs.berkeley.edu/ > >> > >> Happy to discuss more :) > >> > >> Regards > >> Arjuna > >> > >> On 8 October 2013 10:24, Jose Saldana wrote: > >> > Hi all. > >> > > >> > > >> > > >> > I have recently "discovered" the concept of Community Networks. > >> > They are "large scale, self-organized and decentralized networks, > >> > built and operated by citizens for citizens." They are "also > >> > self-owned and self-managed by community members, self-growing in > >> > links, capacity and > >> services provided." > >> > > >> > > >> > > >> > A paper explaining them can be found here: > >> > http://www.sigcomm.org/ccr/papers/2013/July/2500098.2500108 > >> > > >> > > >> > > >> > Some examples: > >> > > >> > http://funkfeuer.at/ > >> > > >> > https://wlan-si.net/ > >> > > >> > http://www.bogota-mesh.org/en > >> > > >> > > >> > > >> > I would like to know your opinion about this: > >> > > >> > > >> > > >> > do you think this is a good idea? > >> > > >> > > >> > > >> > Can they be a good place for developing experiments? > >> > > >> > > >> > > >> > I think this can be a good solution for developing countries. > >> > > >> > > >> > > >> > In addition, regarding TCM-TF, can they be a new scenario where > >> > traffic optimization could be interesting? I mean, they do not have > >> > too much bandwidth, and they connect to the Internet through a > >> > single link in many cases (a bottleneck). One of the services > >> > considered is > > VoIP. > >> > > >> > > >> > > >> > Thanks a lot! > >> > > >> > > >> > > >> > Jose > >> > > >> > > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > From jsaldana@unizar.es Fri Oct 11 08:40:38 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0B21E8120; Fri, 11 Oct 2013 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL2nWwgTUlv7; Fri, 11 Oct 2013 08:40:35 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDAC21E80FA; Fri, 11 Oct 2013 08:40:34 -0700 (PDT) Received: from jsaldanapc (112.Red-88-4-241.dynamicIP.rima-tde.net [88.4.241.112]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r9BFeMbi031407; Fri, 11 Oct 2013 17:40:23 +0200 From: "Jose Saldana" To: , References: <003801cec408$32ea9560$98bfc020$@unizar.es> <000101cec41b$b116ddf0$134499d0$@unizar.es> , <001301cec598$f094d670$d1be8350$@unizar.es> <290E20B455C66743BE178C5C84F12408374274D58A@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408374274D58A@EXMB01CMS.surrey.ac.uk> Subject: RE: [tcmtf] Community Neworks: any idea about them? Date: Fri, 11 Oct 2013 17:40:25 +0200 Message-ID: <000a01cec698$37fefef0$a7fcfcd0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGsCYleI6d2ClbR0uwHsWWEfAsQMQE+g/hmAYGvmKkAwoWkeAFUasQvAUMqX2maBElQAA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:40:38 -0000 Hi, Lloyd. Thanks a lot for the link! It is really interesting: a = country with 1400 people sharing a single satellite connection. In fact, it is similar to Alcalal=ED, the village in Spain, in which also 1400 people = share the Internet access provided by the local Council. (http://www.alcalali.es/ver/137/informacion-general.html).=20 With real-time I was trying to say "services with 100, 200 or 300 ms = delay limit", i.e. the ones we are considering in this tcm-tf draft (http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/?include= _te xt=3D1), i.e. VoIP, online games or remote desktop. Thanks again, Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > l.wood@surrey.ac.uk > Enviado el: jueves, 10 de octubre de 2013 23:46 > Para: jsaldana@unizar.es; tsv-area@ietf.org > CC: tcmtf@ietf.org > Asunto: Re: [tcmtf] Community Neworks: any idea about them? >=20 >=20 > Webcam/chat is realtime. >=20 > http://en.wikipedia.org/wiki/Niue > The island of Niue has a similar free internet model, backhauled via = a satellite > link. >=20 > Lloyd Wood > http://sat-net.com/L.Wood/ >=20 >=20 > ________________________________________ > From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf = Of > Jose Saldana [jsaldana@unizar.es] > Sent: 10 October 2013 10:13 > To: tsv-area@ietf.org > Cc: tcmtf@ietf.org > Subject: RE: [tcmtf] Community Neworks: any idea about them? >=20 > Regarding Community Networks, I have found some information about = their > deployment in rural areas. The Council of a village shares an Internet > connection with all the neighbors, and they get Internet for free. For > example, see this small village (1400 people) called Alcalal=ED, in Alicante, Spain. > http://www.alcalali.es/ver/137/informacion-general.html. >=20 > The question is that, when they talk about the services, they say "Consulta > de p=E1ginas web, descarga de correos, Facebook, Youtube, Yahoo, = Hotmail, > webcam, chats, etc." (web pages, e-mail, Facebook, Youtube, Yahoo, > Hotmail, webcam, chats, etc.). Not a single real-time service is = cited. >=20 > This can be a very interesting use case for TCM-TF: a "bottleneck" = (the > Internet connection) shared by a number of people. If traffic gets optimized, > perhaps they could also offer real-time services like VoIP. >=20 > What do you think? This is working in Spain, but it can also be useful = for > developing countries or zones where network operators have not = deployed > an infrastructure yet. >=20 >=20 > Thanks! >=20 > Jose >=20 > > -----Mensaje original----- > > De: arjuna.sathiaseelan@gmail.com > > [mailto:arjuna.sathiaseelan@gmail.com] > > En nombre de Arjuna Sathiaseelan > > Enviado el: martes, 08 de octubre de 2013 23:43 > > Para: jsaldana@unizar.es > > CC: tcmtf@ietf.org; tsv-area@ietf.org > > Asunto: Re: [tcmtf] Community Neworks: any idea about them? > > > > Hello Jose, > > Any method that utilises the low bandwidth infrastructure more > > efficiently > is > > definitely useful. > > > > Just a digression: have you considered the use of UDP-lite for = TCM-TF? > > > > Regards > > Arjuna > > > > On 8 October 2013 12:44, Jose Saldana wrote: > > > Hi, Arjuna, > > > > > > The idea of multipath TCP sounds interesting. It consists of > > > "inverse multiplexing" with TCP. However, TCM-TF does = "multiplexing" > with UDP. > > > > > > What I was thinking is: can these scenarios also fit with TCM-TF? > > > The idea is to compress small-packet flows (VoIP, online games) in > > > order to save bandwidth, when a number of flows share a common = path. > > > We > > have > > > discarded the multiplexing of TCP, because the additional delay = may > > > modify the dynamics of TCP. > > > > > > TCM-TF combines header compression, multiplexing and tunneling, in > > > order to aggregate a number of flows, when a low-bandwidth link is > > > in the path. Thus, bandwidth can be saved and pps can be reduced, = at > > > the cost of processing power. > > > > > > Do you think this case can be found in these kind of networks? In > > > the discussion of TCM-TF in Berlin this summer, some people from > > > Africa were interested, since they think that low-bandwidth links > > > have to be better used. > > > > > > Thanks! > > > > > > Jose > > > > > >> -----Mensaje original----- > > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En > > >> nombre de Arjuna Sathiaseelan Enviado el: martes, 08 de octubre = de > > >> 2013 > > >> 11:42 > > >> Para: jsaldana@unizar.es > > >> CC: tcmtf@ietf.org; tsv-area@ietf.org > > >> Asunto: Re: [tcmtf] Community Neworks: any idea about them? > > >> > > >> Dear Jose, > > >> I would like to take this opportunity to present some of the = work > > >> we are doing here at Cambridge - > > >> > > >> We are trying to solve the universal service problem in urban = areas > > >> (where people cannot afford to access the Internet) using = existing > > >> home broadband networks - home owners who have Internet > > connections > > >> share their Internet connection for free with those who dont = have. > > >> > > >> We are currently doing deployments in a deprived area in = Nottingham > > >> ( see www.publicaccesswifi.org ) > > >> > > >> More on the LCDNet initiative is here: > > >> http://www.cl.cam.ac.uk/~as2330/lcd/index.html > > >> > > >> There are interesting possibilities to do multi-path TCP between > > > aggregating > > >> multiple access points and we are exploring that option too. > > >> > > >> The TIER group in berkeley have done quite a lot of nice work = with > > > wireless > > >> for developing countries: > > >> tier.cs.berkeley.edu/ > > >> > > >> Happy to discuss more :) > > >> > > >> Regards > > >> Arjuna > > >> > > >> On 8 October 2013 10:24, Jose Saldana wrote: > > >> > Hi all. > > >> > > > >> > > > >> > > > >> > I have recently "discovered" the concept of Community Networks. > > >> > They are "large scale, self-organized and decentralized = networks, > > >> > built and operated by citizens for citizens." They are "also > > >> > self-owned and self-managed by community members, self-growing > in > > >> > links, capacity and > > >> services provided." > > >> > > > >> > > > >> > > > >> > A paper explaining them can be found here: > > >> > http://www.sigcomm.org/ccr/papers/2013/July/2500098.2500108 > > >> > > > >> > > > >> > > > >> > Some examples: > > >> > > > >> > http://funkfeuer.at/ > > >> > > > >> > https://wlan-si.net/ > > >> > > > >> > http://www.bogota-mesh.org/en > > >> > > > >> > > > >> > > > >> > I would like to know your opinion about this: > > >> > > > >> > > > >> > > > >> > do you think this is a good idea? > > >> > > > >> > > > >> > > > >> > Can they be a good place for developing experiments? > > >> > > > >> > > > >> > > > >> > I think this can be a good solution for developing countries. > > >> > > > >> > > > >> > > > >> > In addition, regarding TCM-TF, can they be a new scenario where > > >> > traffic optimization could be interesting? I mean, they do not > > >> > have too much bandwidth, and they connect to the Internet = through > > >> > a single link in many cases (a bottleneck). One of the services > > >> > considered is > > > VoIP. > > >> > > > >> > > > >> > > > >> > Thanks a lot! > > >> > > > >> > > > >> > > > >> > Jose > > >> > > > >> > > > >> _______________________________________________ > > >> tcmtf mailing list > > >> tcmtf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tcmtf > > > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From jsaldana@unizar.es Fri Oct 11 09:26:27 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9021E812E; Fri, 11 Oct 2013 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OsOmg1QD7-g; Fri, 11 Oct 2013 09:26:23 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id C108121E81D8; Fri, 11 Oct 2013 09:26:20 -0700 (PDT) Received: from jsaldanapc (112.Red-88-4-241.dynamicIP.rima-tde.net [88.4.241.112]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r9BGQB4x012400; Fri, 11 Oct 2013 18:26:13 +0200 From: "Jose Saldana" To: "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" References: <003801cec408$32ea9560$98bfc020$@unizar.es> <000101cec41b$b116ddf0$134499d0$@unizar.es> In-Reply-To: Subject: RE: [tcmtf] Community Neworks: any idea about them? Date: Fri, 11 Oct 2013 18:26:13 +0200 Message-ID: <001101cec69e$9bd73db0$d385b910$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGsCYleI6d2ClbR0uwHsWWEfAsQMQE+g/hmAYGvmKkCSQJMb5oM3R2g Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:26:27 -0000 Hi, Mirko. I understand what you mean, but I don't know if considering = TCP is a good idea at this stage. As seen in the BoF in Berlin, many people in the Transport Area are = really worried about adding any extra delay to TCP, since TCP dynamics are = governed by RTT. So my opinion is to forget about standardization of any TCP optimization method. With UDP (or RTP), the thing is more straightforward. In fact, a TCM optimization method for RTP already exists (RFC4170). In my opinion, we need more research, and perhaps an implementation = before considering TCP as a possibility. But I think the best option now is = putting TCP in the fridge until we are able to show real tests showing that TCP flows can be multiplexed (in fact, I have some plans for building an implementation). If we build an implementation, considering RTP, UDP and = TCP is not too much additional work. The IETF believes in running code, so = we will see if TCP optimization "runs" or not. And I am looking for some traces obtained from Community Networks. They = are a very interesting scenario for TCM-TF traffic optimization. Thanks for your feedback! Jose > -----Mensaje original----- > De: Mirko Su=BEnjevi=E6 [mailto:Mirko.Suznjevic@fer.hr] > Enviado el: viernes, 11 de octubre de 2013 15:31 > Para: jsaldana@unizar.es; 'Arjuna Sathiaseelan' > CC: tcmtf@ietf.org; tsv-area@ietf.org > Asunto: RE: [tcmtf] Community Neworks: any idea about them? >=20 > Hello everyone, > While we did get negative feedback on TCP on the IETF meeting in = Berlin, I > am not sure we should completely discard TCP, especially in the cases = in > which the Internet connection is very poor and in which many = devices/users > are using a single connection. Benefits of providing extra bandwidth = in these > conditions could outweigh the downsides of messing up TCP sometimes. > One of the major drawbacks of TCM-TFing TCP was that if we lose a = packet > comprising multiple TCP flows, all of them will reduce their sending = rate at > the same time. Maybe in the conditions of relatively poor Internet > connectivity which occurs in such networks (especially ones which = could be > designed for very poor districts aiming to provide basic connectivity) = the > benefit of providing extra bandwidth would outweigh the downside of > messing up TCP sometimes. > Therefore, I would really like that when we create an implementation = of > TCM-TF we include TCP as well! In this way we could (presuming that we > know the characteristics of the traffic in such networks and characteristics of > such links) performs simulations with and without usage of TCM-TF and = see > whether the results would increase or decrease QoE of the users of = such > networks. > TCM-TF was created in mind to be reactive and react to congestion in certain > parts of the network. In those cases where users require high QoE at = the > start I concur using TCM-TF on TCP could be problematic. On the other hand, > in networks with such bad links it could be employed constantly. As I = said > with proper implementation and simulation and using proper QoE models = we > could see how much benefit or degradation we get. Using it only for = UDP > might yield too little bandwidth savings. Again, it all boils to simulation with > proper realistic traffic mixes and seeing how much gain can we get = with using > only UDP, using both UDP and TCP, and how much does it impact the QoE = of > the users. > To sum it up, I would like us to implement these algorithms and = perform > simulations on realistic traffic mixes. > Is anyone aware of any available traffic traces from such community > networks? > Cheers! > Mirko >=20 > -----Original Message----- > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf > Of Jose Saldana > Sent: Tuesday, October 8, 2013 1:44 PM > To: 'Arjuna Sathiaseelan' > Cc: tcmtf@ietf.org; tsv-area@ietf.org > Subject: Re: [tcmtf] Community Neworks: any idea about them? >=20 > Hi, Arjuna, >=20 > The idea of multipath TCP sounds interesting. It consists of "inverse > multiplexing" with TCP. However, TCM-TF does "multiplexing" with UDP. >=20 > What I was thinking is: can these scenarios also fit with TCM-TF? The = idea is to > compress small-packet flows (VoIP, online games) in order to save > bandwidth, when a number of flows share a common path. We have > discarded the multiplexing of TCP, because the additional delay may = modify > the dynamics of TCP. >=20 > TCM-TF combines header compression, multiplexing and tunneling, in = order > to aggregate a number of flows, when a low-bandwidth link is in the = path. > Thus, bandwidth can be saved and pps can be reduced, at the cost of > processing power. >=20 > Do you think this case can be found in these kind of networks? In the > discussion of TCM-TF in Berlin this summer, some people from Africa = were > interested, since they think that low-bandwidth links have to be = better used. >=20 > Thanks! >=20 > Jose >=20 > > -----Mensaje original----- > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre > > de Arjuna Sathiaseelan Enviado el: martes, 08 de octubre de 2013 = 11:42 > > Para: jsaldana@unizar.es > > CC: tcmtf@ietf.org; tsv-area@ietf.org > > Asunto: Re: [tcmtf] Community Neworks: any idea about them? > > > > Dear Jose, > > I would like to take this opportunity to present some of the work = we > > are doing here at Cambridge - > > > > We are trying to solve the universal service problem in urban areas > > (where people cannot afford to access the Internet) using existing > > home broadband networks - home owners who have Internet connections > > share their Internet connection for free with those who dont have. > > > > We are currently doing deployments in a deprived area in Nottingham = ( > > see www.publicaccesswifi.org ) > > > > More on the LCDNet initiative is here: > > http://www.cl.cam.ac.uk/~as2330/lcd/index.html > > > > There are interesting possibilities to do multi-path TCP between > aggregating > > multiple access points and we are exploring that option too. > > > > The TIER group in berkeley have done quite a lot of nice work with > wireless > > for developing countries: > > tier.cs.berkeley.edu/ > > > > Happy to discuss more :) > > > > Regards > > Arjuna > > > > On 8 October 2013 10:24, Jose Saldana wrote: > > > Hi all. > > > > > > > > > > > > I have recently "discovered" the concept of Community Networks. = They > > > are "large scale, self-organized and decentralized networks, built > > > and operated by citizens for citizens." They are "also self-owned > > > and self-managed by community members, self-growing in links, > > > capacity and > > services provided." > > > > > > > > > > > > A paper explaining them can be found here: > > > http://www.sigcomm.org/ccr/papers/2013/July/2500098.2500108 > > > > > > > > > > > > Some examples: > > > > > > http://funkfeuer.at/ > > > > > > https://wlan-si.net/ > > > > > > http://www.bogota-mesh.org/en > > > > > > > > > > > > I would like to know your opinion about this: > > > > > > > > > > > > do you think this is a good idea? > > > > > > > > > > > > Can they be a good place for developing experiments? > > > > > > > > > > > > I think this can be a good solution for developing countries. > > > > > > > > > > > > In addition, regarding TCM-TF, can they be a new scenario where > > > traffic optimization could be interesting? I mean, they do not = have > > > too much bandwidth, and they connect to the Internet through a > > > single link in many cases (a bottleneck). One of the services > > > considered is > VoIP. > > > > > > > > > > > > Thanks a lot! > > > > > > > > > > > > Jose > > > > > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From michawe@ifi.uio.no Fri Oct 11 23:12:08 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D5221E80B7; Fri, 11 Oct 2013 23:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qw+LmZ9TbKV; Fri, 11 Oct 2013 23:12:03 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id AC60511E81D5; Fri, 11 Oct 2013 23:12:02 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VUsQi-00010m-2d; Sat, 12 Oct 2013 08:12:00 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUsQh-0005Xd-KV; Sat, 12 Oct 2013 08:12:00 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: About the importance of packets in a single data stream Date: Sat, 12 Oct 2013 08:11:59 +0200 Message-Id: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> To: rmcat WG Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 8436 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D35624419EDDA9708629759ED8D7E35D3C519F53 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 281 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:12:08 -0000 Hi, I'll begin by apologizing for asking what I'm quite sure is a terribly = stupid question to many of you. The question is: It has long been known that media data can have different levels of = importance. Simply put, if packet #1 from a single source contains parts = of a video's I-Frame and packet #2 contains only parts of B-Frames, and = both end up in the same queue, controlled by an AQM (for instance), it = would be better for the video stream if packet #2 would be dropped = rather than packet #1. There is nothing new with this story; it's not hard to find research = papers that document various variations of this theme, showing benefits = in video quality. My question is, why is none of this happening? Is it because DSCP values are typically associated with sources, and = hence, marking packet #2 as "less" important would put the source at the = risk of having its packets less important than not only its own other = packets, but anybody else's? But there is equipment that does = per-connection stuff, and such things could probably better be done near = the edges, where the bottleneck typically is... so if that's the whole = issue, we could define DSCP values that mean relative importance *within = the same five-tuple only*. Surely that has been thought about and = probably proposed by folks before, so what happened? Why isn't it done? Or is it because per-five-tuple-functionality in the network is regarded = as being too costly, and not encouraged, and hence not standardized? I'm just trying to understand the reasons for this particular = long-standing difference between research an reality. Cheers, Michael From swmike@swm.pp.se Fri Oct 11 23:28:20 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871C321E8096; Fri, 11 Oct 2013 23:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOmX2WLBHPpR; Fri, 11 Oct 2013 23:28:15 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9135C21F9C12; Fri, 11 Oct 2013 23:28:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E59779C; Sat, 12 Oct 2013 08:28:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DAAC39A; Sat, 12 Oct 2013 08:28:10 +0200 (CEST) Date: Sat, 12 Oct 2013 08:28:10 +0200 (CEST) From: Mikael Abrahamsson To: Michael Welzl Subject: Re: About the importance of packets in a single data stream In-Reply-To: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> Message-ID: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:28:20 -0000 On Sat, 12 Oct 2013, Michael Welzl wrote: > My question is, why is none of this happening? My guess is that the rule to always deliver packets within a stream in order. If packets within the same stream have different DCSP values, there is a risk that they will go into different queues and they might be delivered out of order. A lot of applications that do real-time will have a PDV buffer, but won't have much of a out-of-order buffer. If a packet with sequence number 10 arrives after sequence number 8, packet number 9 is often assumed to be lost. AQM is not widely deployed at all on the Internet as it is today, and a lot of devices will just have 4 different queues. Also as you say below, putting packets into different queues might mean they compete with other traffic and you might get packet loss due to that. It would of course be of interest going forward to look into your proposal. AQM/Bufferbloat movement could perhaps benefit from this, but the current thinking is to make sure that all streams get equal access to the media with minimal influence between them, not that much to decide what packets within a stream to select for drop. -- Mikael Abrahamsson email: swmike@swm.pp.se From michawe@ifi.uio.no Sat Oct 12 01:29:07 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE29D21E80D0; Sat, 12 Oct 2013 01:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axd6OxY+a2bn; Sat, 12 Oct 2013 01:29:01 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id AB21B21E80AF; Sat, 12 Oct 2013 01:28:52 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUuZ7-0000Bp-Bq; Sat, 12 Oct 2013 10:28:49 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUuZ6-0003YZ-Sy; Sat, 12 Oct 2013 10:28:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: About the importance of packets in a single data stream From: Michael Welzl In-Reply-To: Date: Sat, 12 Oct 2013 10:28:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E213C3D-56F2-4F8F-8D96-E7D9A29C6F75@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 8442 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AF1ADC95C82C10E2545DEB4A2FC146267BD5AE56 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 284 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 08:29:07 -0000 On 12. okt. 2013, at 08:28, Mikael Abrahamsson wrote: > On Sat, 12 Oct 2013, Michael Welzl wrote: >=20 >> My question is, why is none of this happening? >=20 > My guess is that the rule to always deliver packets within a stream in = order. If packets within the same stream have different DCSP values, = there is a risk that they will go into different queues and they might = be delivered out of order. A lot of applications that do real-time will = have a PDV buffer, but won't have much of a out-of-order buffer. If a = packet with sequence number 10 arrives after sequence number 8, packet = number 9 is often assumed to be lost. >=20 > AQM is not widely deployed at all on the Internet as it is today, and = a lot of devices will just have 4 different queues. Also as you say = below, putting packets into different queues might mean they compete = with other traffic and you might get packet loss due to that. >=20 > It would of course be of interest going forward to look into your = proposal. AQM/Bufferbloat movement could perhaps benefit from this, but = the current thinking is to make sure that all streams get equal access = to the media with minimal influence between them, not that much to = decide what packets within a stream to select for drop. Thanks, that's about what I guessed... strange, a bit, given that it's = not hard to show quite large quality gains if packet priorities within a = stream (five-tuple) are honored, and doing per-5-tuple things near the = edge doesn't seem all too unusual to me... So indeed it wasn't a proposal, I was just wondering why it's not done. = Maybe not enough interest from the parties involved (because application = developers are not usually the same people that build middle-boxes) Cheers, Michael From michawe@ifi.uio.no Sat Oct 12 01:33:01 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C521E80E8; Sat, 12 Oct 2013 01:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcQpkXNYF+ji; Sat, 12 Oct 2013 01:32:56 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 2221821E80D0; Sat, 12 Oct 2013 01:32:53 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUud1-0001ik-KH; Sat, 12 Oct 2013 10:32:51 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUud1-0001xp-53; Sat, 12 Oct 2013 10:32:51 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: [rmcat] About the importance of packets in a single data stream From: Michael Welzl In-Reply-To: <-774420348401733698@unknownmsgid> Date: Sat, 12 Oct 2013 10:32:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <-774420348401733698@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 11 sum msgs/h 4 total rcpts 8445 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6C80E2B009EE2E4532F607025C6F7F7A7ED78849 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 285 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 08:33:01 -0000 On 12. okt. 2013, at 08:53, Varun Singh wrote: > Hi Michael, >=20 > In my experience, Video telephony applications do not generate any > b-frames. So #2 packets do not exist. Secondly some generate I-frames > only when they really have to (scene change or decoding packet chain > is corrupted) otherwise their GOP is set to infinity. But packet importance is more than just I- vs. P- vs. B-Frames - there = are blocks that depend on each other, and the more data depends on data = in a packet, the more important that packet gets. > For sending I-frames, there are many tricks that a sending endpoint > can play, it doesn't need to burst the whole frame immediately, it can > pace out (there are 10s of milliseconds) before the next frames is > generated. Alternatively, if the frame is too large, they can send > parts of the I-frame with the subsequent frames, this potentially > delays rendering. I don't know if any of these have been standardized. Probably no need to standardize this? > If a part of a frame is lost, the receiver can send a NACK or packet > loss indication Or reference picture selection. >=20 > Another way is that the sending point uses unequal level of protection > (ULP) ie., not all packets or frames are FEC'ed. > Lastly it can vary the packet size, ie., it may do this by varying the > size of slices (combinations of macro blocks). >=20 > Applicability of ARQ typically depends on observed end-to-end delay > and observed losses. The endpoint won't send a nack or a > retransmission if there are too many losses or if it thinks it won't > reach in time for decoding. Yes - the choices are really: 1. add FEC for the more important packets 2. do ARQ when applicable for the more important packets 3. somehow tell the network about the more important packets (but you = can't, normally) and there are trade-offs between these choices. I just wonder if we need = 3. as a part of the API to transport? Cheers, Michael From michawe@ifi.uio.no Sat Oct 12 02:43:28 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA29921F9D65; Sat, 12 Oct 2013 02:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj792OaEwbpc; Sat, 12 Oct 2013 02:43:22 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2321F8EB5; Sat, 12 Oct 2013 02:43:21 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VUvj8-0003E6-Df; Sat, 12 Oct 2013 11:43:14 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUvj7-0000Bv-OA; Sat, 12 Oct 2013 11:43:14 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: [rmcat] About the importance of packets in a single data stream From: Michael Welzl In-Reply-To: Date: Sat, 12 Oct 2013 11:43:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <-774420348401733698@unknownmsgid> To: Varun Singh X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 8448 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F3B681F77563BE6099B8CCEC2897B9B04430B1D3 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 286 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 09:43:28 -0000 On 12. okt. 2013, at 10:49, Varun Singh wrote: > Hi Michael, >=20 > On Sat, Oct 12, 2013 at 11:32 AM, Michael Welzl = wrote: >>=20 >> On 12. okt. 2013, at 08:53, Varun Singh = wrote: >>=20 >>> Hi Michael, >>>=20 >>> In my experience, Video telephony applications do not generate any >>> b-frames. So #2 packets do not exist. Secondly some generate = I-frames >>> only when they really have to (scene change or decoding packet chain >>> is corrupted) otherwise their GOP is set to infinity. >>=20 >> But packet importance is more than just I- vs. P- vs. B-Frames - = there are blocks that depend on each other, and the more data depends on = data in a packet, the more important that packet gets. >>=20 >=20 > At the moment, some systems use unequal level of protection (UEP) to = protect > the packets they think are more important, I suppose what you are = proposing is > to add a kill bit in the packets that are less important. Exactly... > I think there is a tradeoff, redundancy causes overhead (which the > endpoint should > control) and adding priorities pushes the responsibility to the > middlebox and in both > the mechanisms, the sender should probably adapt its rate based on > input from the receiver. Exactly >>> For sending I-frames, there are many tricks that a sending endpoint >>> can play, it doesn't need to burst the whole frame immediately, it = can >>> pace out (there are 10s of milliseconds) before the next frames is >>> generated. Alternatively, if the frame is too large, they can send >>> parts of the I-frame with the subsequent frames, this potentially >>> delays rendering. I don't know if any of these have been = standardized. >>=20 >> Probably no need to standardize this? >>=20 >=20 > Depends where this is done, at the RTP level or elsewhere. If at the = RTP level > there probably needs to be some guidance on how the bits are fed to = the decoding > pipeline from the RTP layer. >>> If a part of a frame is lost, the receiver can send a NACK or packet >>> loss indication Or reference picture selection. >>>=20 >>> Another way is that the sending point uses unequal level of = protection >>> (ULP) ie., not all packets or frames are FEC'ed. >>> Lastly it can vary the packet size, ie., it may do this by varying = the >>> size of slices (combinations of macro blocks). >>>=20 >>> Applicability of ARQ typically depends on observed end-to-end delay >>> and observed losses. The endpoint won't send a nack or a >>> retransmission if there are too many losses or if it thinks it won't >>> reach in time for decoding. >>=20 >> Yes - the choices are really: >> 1. add FEC for the more important packets >> 2. do ARQ when applicable for the more important packets >> 3. somehow tell the network about the more important packets (but = you can't, normally) >>=20 >> and there are trade-offs between these choices. I just wonder if we = need 3. as a part of the API to transport? >>=20 >=20 > when you say transport, you mean DSCP codepoint to indicate to the > middleboxes along the path or > an API from the codec to the transport (RTP/UDP) at the sending = endpoint? I was really only thinking aloud - but what I was thinking about was = indeed a DSCP codepoint that is set because the codec has told the = transport about it, in the API, defined by RMCAT. Cheers, Michael From bernard_aboba@hotmail.com Sat Oct 12 14:00:11 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22CD21E8137; Sat, 12 Oct 2013 14:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5tbUqC4m0mr; Sat, 12 Oct 2013 14:00:06 -0700 (PDT) Received: from blu0-omc4-s2.blu0.hotmail.com (blu0-omc4-s2.blu0.hotmail.com [65.55.111.141]) by ietfa.amsl.com (Postfix) with ESMTP id B53CB21E81C3; Sat, 12 Oct 2013 14:00:05 -0700 (PDT) Received: from BLU169-W46 ([65.55.111.136]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Oct 2013 14:00:06 -0700 X-TMN: [8BLiVc2k5TxJTgeOO65mB6OqATvsFV+2] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c9a6c95a-89e3-4bad-bba3-de0589ac572d_" From: Bernard Aboba To: Michael Welzl , rmcat WG Subject: RE: [rmcat] About the importance of packets in a single data stream Date: Sat, 12 Oct 2013 14:00:05 -0700 Importance: Normal In-Reply-To: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2013 21:00:06.0587 (UTC) FILETIME=[0786A0B0:01CEC78E] Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 21:00:12 -0000 --_c9a6c95a-89e3-4bad-bba3-de0589ac572d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] A few points:=20 a. No B-frames in interactive uses=2C as others have said.=20 b. With SVC=2C you can apply FEC or RTX only to the base layer. So if the= re is loss in the base=2C you can recover. Loss in enhancement layers may = be "lived with" by dropping down to base frame rate/resolution/quality. So= not essential to apply FEC=2C RTX (or QoS) to enhancement layers=2C especi= ally since if there is high loss in enhancement layers a logical response i= s to stop sending them (duh).=20 Michael said:=20 > I'll begin by apologizing for asking what I'm quite sure is a terribly st= upid question to many of you. >=20 > The question is: >=20 > It has long been known that media data can have different levels of impor= tance. Simply put=2C if packet #1 from a single source contains parts of a = video's I-Frame and packet #2 contains only parts of B-Frames=2C and both e= nd up in the same queue=2C controlled by an AQM (for instance)=2C it would = be better for the video stream if packet #2 would be dropped rather than pa= cket #1. >=20 > There is nothing new with this story=3B it's not hard to find research pa= pers that document various variations of this theme=2C showing benefits in = video quality. >=20 > My question is=2C why is none of this happening? >=20 > Is it because DSCP values are typically associated with sources=2C and he= nce=2C marking packet #2 as "less" important would put the source at the ri= sk of having its packets less important than not only its own other packets= =2C but anybody else's? But there is equipment that does per-connection st= uff=2C and such things could probably better be done near the edges=2C wher= e the bottleneck typically is... so if that's the whole issue=2C we could d= efine DSCP values that mean relative importance *within the same five-tuple= only*. Surely that has been thought about and probably proposed by folks b= efore=2C so what happened? Why isn't it done? >=20 > Or is it because per-five-tuple-functionality in the network is regarded = as being too costly=2C and not encouraged=2C and hence not standardized? >=20 > I'm just trying to understand the reasons for this particular long-standi= ng difference between research an reality. >=20 > Cheers=2C > Michael >=20 = --_c9a6c95a-89e3-4bad-bba3-de0589ac572d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] A few points:

a. No= B-frames in interactive uses=2C as others =3B have said.
b. With S= VC=2C you can apply FEC or RTX only to the base layer. =3B =3B So i= f there is loss in the base=2C you can recover. =3B Loss in enhancement= layers may be "lived with" by dropping down to base frame rate/resolution/= quality. =3B So not essential to apply FEC=2C RTX (or QoS) to enhanceme= nt layers=2C especially since if there is high loss in enhancement layers a= logical response is to stop sending them (duh).

Michael sa= id:

>=3B I'll begin by apologizing for asking what I'm quite= sure is a terribly stupid question to many of you.
>=3B
>=3B Th= e question is:
>=3B
>=3B It has long been known that media data = can have different levels of importance. Simply put=2C if packet #1 from a = single source contains parts of a video's I-Frame and packet #2 contains on= ly parts of B-Frames=2C and both end up in the same queue=2C controlled by = an AQM (for instance)=2C it would be better for the video stream if packet = #2 would be dropped rather than packet #1.
>=3B
>=3B There is no= thing new with this story=3B it's not hard to find research papers that doc= ument various variations of this theme=2C showing benefits in video quality= .
>=3B
>=3B My question is=2C why is none of this happening?
= >=3B
>=3B Is it because DSCP values are typically associated with s= ources=2C and hence=2C marking packet #2 as "less" important would put the = source at the risk of having its packets less important than not only its o= wn other packets=2C but anybody else's? But there is equipment that does p= er-connection stuff=2C and such things could probably better be done near t= he edges=2C where the bottleneck typically is... so if that's the whole iss= ue=2C we could define DSCP values that mean relative importance *within the= same five-tuple only*. Surely that has been thought about and probably pro= posed by folks before=2C so what happened? Why isn't it done?
>=3B >=3B Or is it because per-five-tuple-functionality in the network is reg= arded as being too costly=2C and not encouraged=2C and hence not standardiz= ed?
>=3B
>=3B I'm just trying to understand the reasons for this= particular long-standing difference between research an reality.
>=3B=
>=3B Cheers=2C
>=3B Michael
>=3B
= --_c9a6c95a-89e3-4bad-bba3-de0589ac572d_-- From michawe@ifi.uio.no Sun Oct 13 01:01:46 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F156A21E80BB; Sun, 13 Oct 2013 01:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZhtp5qrTlSb; Sun, 13 Oct 2013 01:01:40 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 3917021E8088; Sun, 13 Oct 2013 01:01:38 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVGcJ-0006IQ-Uj; Sun, 13 Oct 2013 10:01:35 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVGcJ-0007Sw-9R; Sun, 13 Oct 2013 10:01:35 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217" Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: [rmcat] About the importance of packets in a single data stream From: Michael Welzl In-Reply-To: Date: Sun, 13 Oct 2013 10:01:33 +0200 Message-Id: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> To: Bernard Aboba X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 8453 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 26BA31724B96B2B454720E293C2CA2F8047778A8 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 289 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 08:01:46 -0000 --Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12. okt. 2013, at 23:00, Bernard Aboba = wrote: > [BA] A few points:=20 >=20 > a. No B-frames in interactive uses, as others have said.=20 > b. With SVC, you can apply FEC or RTX only to the base layer. So if = there is loss in the base, you can recover. Loss in enhancement layers = may be "lived with" by dropping down to base frame = rate/resolution/quality. So not essential to apply FEC, RTX (or QoS) to = enhancement layers, especially since if there is high loss in = enhancement layers a logical response is to stop sending them (duh).=20 I see. Well, should we perhaps really suggest a = "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then? Cheers, Michael >=20 >=20 >=20 > Michael said:=20 >=20 > > I'll begin by apologizing for asking what I'm quite sure is a = terribly stupid question to many of you. > >=20 > > The question is: > >=20 > > It has long been known that media data can have different levels of = importance. Simply put, if packet #1 from a single source contains parts = of a video's I-Frame and packet #2 contains only parts of B-Frames, and = both end up in the same queue, controlled by an AQM (for instance), it = would be better for the video stream if packet #2 would be dropped = rather than packet #1. > >=20 > > There is nothing new with this story; it's not hard to find research = papers that document various variations of this theme, showing benefits = in video quality. > >=20 > > My question is, why is none of this happening? > >=20 > > Is it because DSCP values are typically associated with sources, and = hence, marking packet #2 as "less" important would put the source at the = risk of having its packets less important than not only its own other = packets, but anybody else's? But there is equipment that does = per-connection stuff, and such things could probably better be done near = the edges, where the bottleneck typically is... so if that's the whole = issue, we could define DSCP values that mean relative importance *within = the same five-tuple only*. Surely that has been thought about and = probably proposed by folks before, so what happened? Why isn't it done? > >=20 > > Or is it because per-five-tuple-functionality in the network is = regarded as being too costly, and not encouraged, and hence not = standardized? > >=20 > > I'm just trying to understand the reasons for this particular = long-standing difference between research an reality. > >=20 > > Cheers, > > Michael > > --Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 12. okt. 2013, = at 23:00, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

[BA] A few points:

a. No B-frames in = interactive uses, as others have said.
b. With SVC, you can = apply FEC or RTX only to the base layer. So if there is loss = in the base, you can recover. Loss in enhancement layers may be = "lived with" by dropping down to base frame = rate/resolution/quality. So not essential to apply FEC, RTX (or = QoS) to enhancement layers, especially since if there is high loss in = enhancement layers a logical response is to stop sending them = (duh).
=

I see. Well, should we perhaps really suggest a = "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP = then?

Cheers,
Michael

Michael said:

> I'll = begin by apologizing for asking what I'm quite sure is a terribly stupid = question to many of you.
>
> The question = is:
>
> = It has long been known that media data can have different levels of = importance. Simply put, if packet #1 from a single source contains parts = of a video's I-Frame and packet #2 contains only parts of B-Frames, and = both end up in the same queue, controlled by an AQM (for instance), it = would be better for the video stream if packet #2 would be dropped = rather than packet #1.
>
> There is nothing = new with this story; it's not hard to find research papers that document = various variations of this theme, showing benefits in video = quality.
>
> My question is, = why is none of this happening?
>
> Is it because DSCP = values are typically associated with sources, and hence, marking packet = #2 as "less" important would put the source at the risk of having its = packets less important than not only its own other packets, but anybody = else's? But there is equipment that does per-connection stuff, and such = things could probably better be done near the edges, where the = bottleneck typically is... so if that's the whole issue, we could define = DSCP values that mean relative importance *within the same five-tuple = only*. Surely that has been thought about and probably proposed by folks = before, so what happened? Why isn't it done?
>
> Or is it because = per-five-tuple-functionality in the network is regarded as being too = costly, and not encouraged, and hence not standardized?
>
> I'm just trying to = understand the reasons for this particular long-standing difference = between research an reality.
>
> Cheers,
> = Michael
>

= --Apple-Mail=_5703C864-91C5-4267-85E6-10BCBA20A217-- From michawe@ifi.uio.no Sun Oct 13 09:28:43 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9483911E8163; Sun, 13 Oct 2013 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MBL8bNatoDa; Sun, 13 Oct 2013 09:28:38 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id F254211E8151; Sun, 13 Oct 2013 09:28:37 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVOWx-0004vL-N1; Sun, 13 Oct 2013 18:28:35 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.104]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVOWw-0003E6-RX; Sun, 13 Oct 2013 18:28:35 +0200 References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F Message-Id: X-Mailer: iPhone Mail (9B206) From: Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream Date: Sun, 13 Oct 2013 18:28:34 +0200 To: Kevin Gross X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 8460 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 21728D0FC4F17EA0F56CB0E4198F889B32D4DBAE X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 292 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:28:43 -0000 --Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IP? with a clear "per-5-tuple-only" rule? Sent from my iPhone On 13. okt. 2013, at 17:29, Kevin Gross wrote: > There have been mechanisms proposed or implemented to some extent in Ether= net, ATM and IP for indicating drop precedence (as opposed to class). These m= echanisms are designed to solve exactly this problem. I'm not sure why this c= apability has, by and large, not been widely deployed. I think, for one, we n= etwork propeller-heads tend to overestimate the importance of QoS or at leas= t the ability of application designers and IT personnel to get their heads a= round it well enough to be able to configure it so that it actually improves= things. >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com >=20 >=20 > On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl wrote:= >=20 > On 12. okt. 2013, at 23:00, Bernard Aboba wrot= e: >=20 >> [BA] A few points:=20 >>=20 >> a. No B-frames in interactive uses, as others have said.=20 >> b. With SVC, you can apply FEC or RTX only to the base layer. So if the= re is loss in the base, you can recover. Loss in enhancement layers may be "= lived with" by dropping down to base frame rate/resolution/quality. So not e= ssential to apply FEC, RTX (or QoS) to enhancement layers, especially since i= f there is high loss in enhancement layers a logical response is to stop sen= ding them (duh).=20 >=20 > I see. Well, should we perhaps really suggest a "lower-priority-than-other= -packets-in-the-same-5-tuple" DSCP then? >=20 > Cheers, > Michael >=20 >=20 >=20 >>=20 >>=20 >>=20 >> Michael said:=20 >>=20 >> > I'll begin by apologizing for asking what I'm quite sure is a terribly s= tupid question to many of you. >> >=20 >> > The question is: >> >=20 >> > It has long been known that media data can have different levels of imp= ortance. Simply put, if packet #1 from a single source contains parts of a v= ideo's I-Frame and packet #2 contains only parts of B-Frames, and both end u= p in the same queue, controlled by an AQM (for instance), it would be better= for the video stream if packet #2 would be dropped rather than packet #1. >> >=20 >> > There is nothing new with this story; it's not hard to find research pa= pers that document various variations of this theme, showing benefits in vid= eo quality. >> >=20 >> > My question is, why is none of this happening? >> >=20 >> > Is it because DSCP values are typically associated with sources, and he= nce, marking packet #2 as "less" important would put the source at the risk o= f having its packets less important than not only its own other packets, but= anybody else's? But there is equipment that does per-connection stuff, and s= uch things could probably better be done near the edges, where the bottlenec= k typically is... so if that's the whole issue, we could define DSCP values t= hat mean relative importance *within the same five-tuple only*. Surely that h= as been thought about and probably proposed by folks before, so what happene= d? Why isn't it done? >> >=20 >> > Or is it because per-five-tuple-functionality in the network is regarde= d as being too costly, and not encouraged, and hence not standardized? >> >=20 >> > I'm just trying to understand the reasons for this particular long-stan= ding difference between research an reality. >> >=20 >> > Cheers, >> > Michael >> > >=20 >=20 --Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
IP? with a clear "per-5-tuple-only" rule?

Sent from my iPhone

On 13. okt. 2013, at 17:29, Kevin Gross <kevin.gross@avanw.com> wrote:

There have been mechanisms proposed or implemented to some extent in Ethernet, ATM and IP for indicating drop precedence (as opposed to class). These mechanisms are designed to solve exactly this problem. I'm not sure why this capability has, by and large, not been widely deployed. I think, for one, we network propeller-heads tend to overestimate the importance of QoS or at least the ability of application designers and IT personnel to get their heads around it well enough to be able to configure it so that it actually improves things.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com

On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

On 12. okt. 2013, at 23:00, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

[BA] A few points:

a. No B-frames in interactive uses, as others have said.
b. With SVC, you can apply FEC or RTX only to the base layer. So if there is loss in the base, you can recover. Loss in enhancement layers may be "lived with" by dropping down to base frame rate/resolution/quality. So not essential to apply FEC, RTX (or QoS) to enhancement layers, especially since if there is high loss in enhancement layers a logical response is to stop sending them (duh).

I see. Well, should we perhaps really suggest a "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then?

Cheers,
Michael

Michael said:

> I'll begin by apologizing for asking what I'm quite sure is a terribly stupid question to many of you.
>
> The question is:
>
> It has long been known that media data can have different levels of importance. Simply put, if packet #1 from a single source contains parts of a video's I-Frame and packet #2 contains only parts of B-Frames, and both end up in the same queue, controlled by an AQM (for instance), it would be better for the video stream if packet #2 would be dropped rather than packet #1.
>
> There is nothing new with this story; it's not hard to find research papers that document various variations of this theme, showing benefits in video quality.
>
> My question is, why is none of this happening?
>
> Is it because DSCP values are typically associated with sources, and hence, marking packet #2 as "less" important would put the source at the risk of having its packets less important than not only its own other packets, but anybody else's? But there is equipment that does per-connection stuff, and such things could probably better be done near the edges, where the bottleneck typically is... so if that's the whole issue, we could define DSCP values that mean relative importance *within the same five-tuple only*. Surely that has been thought about and probably proposed by folks before, so what happened? Why isn't it done?
>
> Or is it because per-five-tuple-functionality in the network is regarded as being too costly, and not encouraged, and hence not standardized?
>
> I'm just trying to understand the reasons for this particular long-standing difference between research an reality.
>
> Cheers,
> Michael
>

--Apple-Mail-1B83CF31-F456-46CD-BCFF-EB98A4F07B7F-- From allison.mankin@gmail.com Sun Oct 13 16:30:26 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4911E80F7; Sun, 13 Oct 2013 16:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY2Bz+HdIuth; Sun, 13 Oct 2013 16:30:25 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5321F9C8E; Sun, 13 Oct 2013 16:30:25 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id mz11so2427318bkb.9 for ; Sun, 13 Oct 2013 16:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VIzJ8rXAehrPN6zzpn/vxz4WWjCM5ZtmO7k9AsEEMJQ=; b=RF3Vj4lNZKZnahQWdyd+dkU5HBzrxercK+lQHPcWjEjPvIZ8jS14GkYtc2TwEXQpwe +/HecxfmZmUZ0mSrjGU9XfcJxwr3y4hnv5Y6CDX6WZNQOoqNUBuBHf1FqiLU/5wAE4If gk4qrW6sN5EDoC338xSKB5+nay/47KGQITA9NCvXDhkfYOXkL95L0VCXRU1NI9Lx5PuL qrCbAKOPrsK1ogkaFfNnkHZpobI5s5Kk0qIKxL/P4renRcwyS2wdjvB6sb8cOBVRUEqY T+so0zxlTzCcKz/+peomNJmWVovQi6HUv6Cquy7qt6llJHSxGqckJKI63fnCcxMqtec1 wJkw== MIME-Version: 1.0 X-Received: by 10.205.86.199 with SMTP id at7mr27640015bkc.9.1381707024305; Sun, 13 Oct 2013 16:30:24 -0700 (PDT) Received: by 10.205.14.68 with HTTP; Sun, 13 Oct 2013 16:30:24 -0700 (PDT) Date: Sun, 13 Oct 2013 19:30:24 -0400 Message-ID: Subject: NOMCOM 2013 - Need TSV Candidates From: Allison Mankin To: Transport Area Content-Type: text/plain; charset=ISO-8859-1 Cc: Nomcom Chair 2013 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 23:30:26 -0000 Hi, TSV-area folks, We are very low on candidates for the TSV AD position. Even if you support the present incumbent, there's a lot to be said for accepting a nomination - you'll have learned about your company's willingness to support; you'll have filled out the questionnaire, which I've always found to be a good opportunity to think about one's area and about the IETF; and you'll have experienced and contributed to the nomcom process overall, a key part of the IETF's culture. This process only works because many IETFers take part; please join in. Nominate yourself, or nominate someone whom you've observed working, someone who you think is showing leadership potential, someone who could be a great AD. If there's someone who you think should be an AD in future, ask her or him to consider accepting a nomination now. Deadline for nominations is October 18. Nominate soon to give your nominee(s) enough time to fill in the questionnaire, which is due October 25. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! From michawe@ifi.uio.no Mon Oct 14 04:17:42 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF48C11E8127; Mon, 14 Oct 2013 04:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awrqPS4xzxK4; Mon, 14 Oct 2013 04:17:26 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id AA99B11E8186; Mon, 14 Oct 2013 04:16:10 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VVg7Z-0007PF-Uu; Mon, 14 Oct 2013 13:15:33 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVg7Z-0005AW-BW; Mon, 14 Oct 2013 13:15:33 +0200 Subject: Re: [rmcat] About the importance of packets in a single data stream Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20131014063911.GA32524@cisco.com> Date: Mon, 14 Oct 2013 13:15:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> References: <20131014063911.GA32524@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 8485 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 874065BFD50FD5654A75CBE16F11E4533480B0C2 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3318 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:17:43 -0000 Hi, That was a very interesting answer, thanks! Comments in line: On 14. okt. 2013, at 08:39, Toerless Eckert wrote: >=20 > High level answer: I think it has not been done so far because it is = not that > easy, and it requires both good thinking of how to do it from the = video encoding > expert and the network QoS experts.=20 >=20 > I think it would be great if video flows would give per-packet = priority > indications. I think most of the reasons brought up so far in this = thread are no good > reasons not to do it: I agree! > - Even without B frames, different packets can have different = prioties. I/LTR > frames vs. P frames for example. Equally in SVC. > - FEC is not free but costs quite a bit of overhead. And its not = particularily > well protecting against burst loss happening during burst collisions = when > new competing flows cause queue overrun. > - Playout buffers in receiver apps can be quite large. STBs supposedly = have > 100 msec or more. So reordering of different priority packets should = not > be an issue. Even with low-delay video, the reordering that could = happen > in the network just means that some packets of the flow arrive = earlier than > expected under the contention conditions. Besides, you can also have = different > drop priorities without packet reordering within the same queue. In = fact > AF4x for example is defined to have that property (no packet = reordering). >=20 > IMHO, the issues why nothing has been done so far are rather: >=20 > - There may not be enough well understood value analysis, eg: How well = could > network with differentiated drop policies effectively protect higher > priority packets over lower priority packets. Yes, this is widely = known at > the class level, but not necessarily for packet distributions of = different > packets in the same flow. We've done some simulations on this that we > could show that IMHO looked pretty good. At least to some degree, this must be a function of the queue length, I = think. The shorter your queue, the less likely it is that you see more = than one packet from the same source... if important packet #1 from = source X and unimportant packet #2 from source X are not in the same = queue together, you probably can't reasonably protect #1 from the impact = of #2. > - Why drop if you could do ECN plus rate-adaptive downspeeding. The = answer is=20 > IMHO a bit more complex. I agree. > In summary, i think priority dropping is good to > deal with short term burst collisions and i think they can become = quite likely > for RMCAT. For dealing with ongoing congestion you obviously want = downspeeding, > and ongoing may be as short as maybe >=3D 2..10 seconds. If you do = have > priority based drop support in the network, i think that could fare = better > than ECN because it does resolve the burst collision as good as = possibe > in addition to a congestion notification. PCN of course would be best = to have, > in which case the window of applicability for priority dropping = shrinks to > less likely burst collisions. >=20 > - How do you maximize the value of priority dropping in the video = codec. > Ideally you build your codec to have real discardable frames that are = not > predictor for other frames. But that as PSNR impacts. So this gets = into > the secret sauce of codecs. There, I think the answer can easily be found in multimedia literature. = There are many papers out there that evaluate such effects, e.g.: Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video = Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom = MoVID 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil. as only one example. > - How do you signal packet priority. DSCP is really ugly (TM). = Besides, its > really ugly to set from application (TM). An RTP header extension = field > would be IMHO much nicer. I agree that DSCP is ugly; I was thinking that one would have to even = reserve bits in DSCP because, despite different priorities *within* a = connection, one might still apply e.g. DiffServ to differentiate between = 5-tuples. Indeed, given that this is functionality that's only meant for = devices that identify 5-tuples, something above IP would make sense. So = I think I agree that an RTP header extension would be a good choice. > - How do you motivate codecs to indicate packet priorities if they = have to > fear that video flows with some packets marked "low priority" would > ultimately see more packets dropped than flows without any "low = priority" > indications. For that we've got draft-lai-tsvwg-normalizer-02.txt Well, but here we're talking about a marking that only means "relative = priority, within the same connection". So there shouldn't be any risk in = setting low priority, really. Cheers, Michael From eckert@cisco.com Mon Oct 14 07:37:31 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB711E8189; Mon, 14 Oct 2013 07:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.673 X-Spam-Level: X-Spam-Status: No, score=-8.673 tagged_above=-999 required=5 tests=[AWL=1.926, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSFrnsSV2kEb; Mon, 14 Oct 2013 07:37:26 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A272A11E8147; Mon, 14 Oct 2013 07:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2040; q=dns/txt; s=iport; t=1381761446; x=1382971046; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=55KpbIiVIttTvybjx3lqz9Pf/IdvbgK/SpId/md947I=; b=mZflYBdojF70aTkQU2zMv6WddyKC/ySWhvaT5cx4UZ97DHQPD/tIE+IC vrdfErAwKPYKv0q9ys4fcWjNqSzt6E9yo+txAcvxkBs/LZxgSjpSZHEpx ANLamkJeCoMEdV5KFsPTEnoZDTt2+7grCK3e21wGqpcS5Om1pLORQMTkJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHQAXFKrRDoJ/2dsb2JhbABZgwfCeYEkFnSCJQEBAQMBOj8FCwsOBAYJJQ8FNRQTiAAFvXmPUgeDH4EEA4k8jkgBkgKDRBw X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208";a="94685395" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Oct 2013 14:37:24 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9EEbN7B026803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 14:37:23 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9EEbNrK023646; Mon, 14 Oct 2013 07:37:23 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9EEbNVr023645; Mon, 14 Oct 2013 07:37:23 -0700 Date: Mon, 14 Oct 2013 07:37:23 -0700 From: Toerless Eckert To: Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream Message-ID: <20131014143723.GB32524@cisco.com> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:37:32 -0000 On Mon, Oct 14, 2013 at 01:15:31PM +0200, Michael Welzl wrote: > At least to some degree, this must be a function of the queue length, I think. The shorter your queue, the less likely it is that you see more than one packet from the same source... if important packet #1 from source X and unimportant packet #2 from source X are not in the same queue together, you probably can't reasonably protect #1 from the impact of #2. Indeed. IN other words you need some number of multiplexed flows to effectively do intelligent dropping. I think this may be as low as 3..4 flows on a home-gateway, but the more, the better. > There, I think the answer can easily be found in multimedia literature. There are many papers out there that evaluate such effects, e.g.: > Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom MoVID 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil. > as only one example. Thanks for the pointer. > > - How do you motivate codecs to indicate packet priorities if they have to > > fear that video flows with some packets marked "low priority" would > > ultimately see more packets dropped than flows without any "low priority" > > indications. For that we've got draft-lai-tsvwg-normalizer-02.txt > > Well, but here we're talking about a marking that only means "relative priority, within the same connection". So there shouldn't be any risk in setting low priority, really. But you need an intelligent dropping mechanism, and unless you would do a per-flow subqueue, you could not do relative dropping relative within the flow). And per-flow queuing is expensive. So our draft tries to explain a scheme that replaces per-floq queuing with per-flow priority remarking to allow dropping in a common queue. Cheers toerless > Cheers, > Michael > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From slblake@petri-meat.com Mon Oct 14 17:58:33 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A27121E8140; Mon, 14 Oct 2013 17:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oA7Geykdj-B; Mon, 14 Oct 2013 17:58:28 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id E46BD21E8100; Mon, 14 Oct 2013 17:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=petri-meat.com; s=default; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID; bh=jeiA0k/5kh7lJbW63xgdv5j7YLChCLrvJ0cszlaBtSo=; b=N8pF99zmYT0i5PF+bJblEtHNrB4D9Ho4GH6RqX+VytrDaJeBb8dj9azciI1z4UU1hqS3dKzdSd9pMXtWqCuo2/f6YILoyTN6JHK/VzxnvtQYGecfWJzRbGQszWSNP7Tu; Received: from cpe-098-027-048-172.nc.res.rr.com ([98.27.48.172]:42817 helo=[192.168.144.50]) by elom.tchmachines.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VVsxo-0001Qq-L0; Mon, 14 Oct 2013 20:58:20 -0400 Message-ID: <1381798705.7804.22.camel@tachyon.blake> Subject: Re: About the importance of packets in a single data stream From: Steven Blake To: Michael Welzl Date: Mon, 14 Oct 2013 20:58:25 -0400 In-Reply-To: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Get-Message-Sender-Via: elom.tchmachines.com: authenticated_id: slblake+petri-meat.com/only user confirmed/virtual account not confirmed Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 00:58:33 -0000 On Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote: > Hi, > > I'll begin by apologizing for asking what I'm quite sure is a terribly > stupid question to many of you. > > The question is: > > It has long been known that media data can have different levels of > importance. Simply put, if packet #1 from a single source contains > parts of a video's I-Frame and packet #2 contains only parts of > B-Frames, and both end up in the same queue, controlled by an AQM (for > instance), it would be better for the video stream if packet #2 would > be dropped rather than packet #1. > > There is nothing new with this story; it's not hard to find research > papers that document various variations of this theme, showing > benefits in video quality. > > My question is, why is none of this happening? > > Is it because DSCP values are typically associated with sources, and > hence, marking packet #2 as "less" important would put the source at > the risk of having its packets less important than not only its own > other packets, but anybody else's? But there is equipment that does > per-connection stuff, and such things could probably better be done > near the edges, where the bottleneck typically is... so if that's the > whole issue, we could define DSCP values that mean relative importance > *within the same five-tuple only*. Surely that has been thought about > and probably proposed by folks before, so what happened? Why isn't it > done? > > Or is it because per-five-tuple-functionality in the network is > regarded as being too costly, and not encouraged, and hence not > standardized? > > I'm just trying to understand the reasons for this particular > long-standing difference between research an reality. The Assured Forwarding (AF) PHB group (RFC2597) was defined precisely to enable this drop-precedence-without-reordering-packets-within-a-flow behavior. In Diffserv jargon (RFC3260), an instance of an AF behavior aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered aggregate (OA). Packets in a flow DSCP-encoded with either AF11/AF12/AF13 (for example) are guaranteed to be transmitted in the order received, but will have different drop precedences (AF11 highest; AF13 lowest). This is usually achieved by serving all packets on a port with the AF1* DSCP via the same FIFO queue. Regards, // Steve From michawe@ifi.uio.no Tue Oct 15 01:06:52 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1924121E8096; Tue, 15 Oct 2013 01:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdNiuvNUXc4f; Tue, 15 Oct 2013 01:06:47 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6067021E8123; Tue, 15 Oct 2013 01:06:38 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVzeE-0008CZ-3t; Tue, 15 Oct 2013 10:06:34 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VVzeD-0007kL-If; Tue, 15 Oct 2013 10:06:34 +0200 Subject: Re: [rmcat] About the importance of packets in a single data stream Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F" From: Michael Welzl In-Reply-To: <20131014143723.GB32524@cisco.com> Date: Tue, 15 Oct 2013 10:06:32 +0200 Message-Id: <289D7CCD-0C73-4596-B6F0-053202C46BA2@ifi.uio.no> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <20131014143723.GB32524@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 8553 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EE6DEAECFF07644ED798B1FA7AC6CB9D679FBD27 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3336 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:06:52 -0000 --Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> - How do you motivate codecs to indicate packet priorities if they = have to >>> fear that video flows with some packets marked "low priority" would >>> ultimately see more packets dropped than flows without any "low = priority" >>> indications. For that we've got draft-lai-tsvwg-normalizer-02.txt >>=20 >> Well, but here we're talking about a marking that only means = "relative priority, within the same connection". So there shouldn't be = any risk in setting low priority, really. >=20 > But you need an intelligent dropping mechanism, and unless you would > do a per-flow subqueue, you could not do relative dropping relative = within > the flow). And per-flow queuing is expensive. So our draft tries to = explain a scheme > that replaces per-floq queuing with per-flow priority remarking to = allow > dropping in a common queue. So now I finally read = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I = like it a lot! It is indeed exactly what we need - but one issue with it = is compatibility. Actually this could become a show-stopper, as this is = all about getting the incentives right: why would my application ever = set a higher drop precedence for some packets when I don't know if this = normalizer is in place or not? And this decision would have to be taken = by the application... I could imagine a scenario where an application inserts the RTP = extension header that you mentioned, and then a flow-aware edge device = which knows that this traffic is going to traverse a path where your = normalization marker is in place marks packets into an AFx PHB group = based on the RTP extension header. Then we have an architecture that is = incentive-compatible AND scales. Cheers, Michael --Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
- How do you motivate codecs to = indicate packet priorities if they have = to
fear that video flows with some packets marked "low = priority" would
ultimately see more packets = dropped than flows without any "low = priority"
indications. For that we've got = draft-lai-tsvwg-normalizer-02.txt

Well, but here = we're talking about a marking that only means "relative priority, within = the same connection". So there shouldn't be any risk in setting low = priority, really.

But you need an intelligent = dropping mechanism, and unless you would
do a per-flow subqueue, you = could not do relative dropping relative within
the flow). And = per-flow queuing is expensive. So our draft tries to explain a = scheme
that replaces per-floq queuing with per-flow priority = remarking to allow
dropping in a common = queue.

So now I finally = read http://tool= s.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I = like it a lot! It is indeed exactly what we need - but one issue with it = is compatibility. Actually this could become a show-stopper, as this is = all about getting the incentives right: why would my application = ever set a higher drop precedence for some packets when I don't know if = this normalizer is in place or not? And this decision would have to be = taken by the application...

I could imagine a = scenario where an application inserts the RTP extension header that you = mentioned, and then a flow-aware edge device which knows that this = traffic is going to traverse a path where your normalization marker is = in place marks packets into an AFx PHB group based on the RTP extension = header. Then we have an architecture that is incentive-compatible AND = scales.

Cheers,
Michael

<= /div>= --Apple-Mail=_DEA2E69B-FEA7-499E-8A21-0D65D3CDD50F-- From michawe@ifi.uio.no Tue Oct 15 01:15:06 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DF511E812A; Tue, 15 Oct 2013 01:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwZcN16Iwhd6; Tue, 15 Oct 2013 01:15:00 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 802AB21F9FFF; Tue, 15 Oct 2013 01:14:48 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VVzmB-0002Tk-8x; Tue, 15 Oct 2013 10:14:47 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VVzmA-00066A-Bp; Tue, 15 Oct 2013 10:14:47 +0200 Subject: Re: About the importance of packets in a single data stream Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569" From: Michael Welzl In-Reply-To: <1381798705.7804.22.camel@tachyon.blake> Date: Tue, 15 Oct 2013 10:14:45 +0200 Message-Id: References: <01913F56-8B19-4BF1-AE8C-0D01A5055BB9@ifi.uio.no> <1381798705.7804.22.camel@tachyon.blake> To: Steven Blake X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 8556 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 50EEE57544926CF9B7E36361B1D131A02BFFF810 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3337 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:15:06 -0000 --Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15. okt. 2013, at 02:58, Steven Blake wrote: > On Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote: >=20 >> Hi, >>=20 >> I'll begin by apologizing for asking what I'm quite sure is a = terribly >> stupid question to many of you. >>=20 >> The question is: >>=20 >> It has long been known that media data can have different levels of >> importance. Simply put, if packet #1 from a single source contains >> parts of a video's I-Frame and packet #2 contains only parts of >> B-Frames, and both end up in the same queue, controlled by an AQM = (for >> instance), it would be better for the video stream if packet #2 would >> be dropped rather than packet #1. >>=20 >> There is nothing new with this story; it's not hard to find research >> papers that document various variations of this theme, showing >> benefits in video quality. >>=20 >> My question is, why is none of this happening? >>=20 >> Is it because DSCP values are typically associated with sources, and >> hence, marking packet #2 as "less" important would put the source at >> the risk of having its packets less important than not only its own >> other packets, but anybody else's? But there is equipment that does >> per-connection stuff, and such things could probably better be done >> near the edges, where the bottleneck typically is... so if that's the >> whole issue, we could define DSCP values that mean relative = importance >> *within the same five-tuple only*. Surely that has been thought about >> and probably proposed by folks before, so what happened? Why isn't it >> done? >>=20 >> Or is it because per-five-tuple-functionality in the network is >> regarded as being too costly, and not encouraged, and hence not >> standardized? >>=20 >> I'm just trying to understand the reasons for this particular >> long-standing difference between research an reality. >=20 > The Assured Forwarding (AF) PHB group (RFC2597) was defined precisely = to > enable this drop-precedence-without-reordering-packets-within-a-flow > behavior. In Diffserv jargon (RFC3260), an instance of an AF behavior > aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered aggregate > (OA). Packets in a flow DSCP-encoded with either AF11/AF12/AF13 (for > example) are guaranteed to be transmitted in the order received, but > will have different drop precedences (AF11 highest; AF13 lowest). = This > is usually achieved by serving all packets on a port with the AF1* = DSCP > via the same FIFO queue. No, this is not what I mean. =46rom RFC2597: In a DS node, the level of forwarding assurance of an IP packet thus depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet. So while AF PHB groups are indeed meant to address such per-flow drop = precedence, we still have a per-aggregate function, meaning that it's = risky business for an application to decide that some of its packets = have a higher drop precedence (it might put the application at a = disadvantage in comparison with other *users*). If you just look at page 4 of = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 (Flow A vs. = Flow B) you'll see an example that explains exactly the problem I'm = talking about. Indeed I think that this draft suggests a nice solution, = but as long as an application doesn't know that the mechanism in this = draft is in place everywhere, the incentive for an application to assign = a higher drop precedence to some packets still isn't there. For how I think this could be solved, see my previous email to Toerless. Cheers, Michael --Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote:

Hi,

I'll begin by = apologizing for asking what I'm quite sure is a = terribly
stupid question to = many of you.

The question = is:

It has long been known that media data can have different = levels of
importance. Simply = put, if packet #1 from a single source = contains
parts of a video's = I-Frame and packet #2 contains only parts of
B-Frames, and both end up in the same queue, controlled by = an AQM (for
instance), it = would be better for the video stream if packet #2 = would
be dropped rather than = packet #1.

There is = nothing new with this story; it's not hard to find = research
papers that document = various variations of this theme, showing
benefits in video quality.

My question is, = why is none of this happening?

Is it because = DSCP values are typically associated with sources, = and
hence, marking packet #2 = as "less" important would put the source at
the risk of having its packets less important than not = only its own
other packets, = but anybody else's? But there is equipment that = does
per-connection stuff, and = such things could probably better be done
near the edges, where the bottleneck typically is... so if = that's the
whole issue, we = could define DSCP values that mean relative = importance
*within the same = five-tuple only*. Surely that has been thought = about
and probably proposed by = folks before, so what happened? Why isn't it
done?

Or is it = because per-five-tuple-functionality in the network = is
regarded as being too = costly, and not encouraged, and hence not
standardized?

I'm just trying = to understand the reasons for this = particular
long-standing = difference between research an reality.

The Assured = Forwarding (AF) PHB group (RFC2597) was defined precisely to
enable = this = drop-precedence-without-reordering-packets-within-a-flow
behavior. = In Diffserv jargon (RFC3260), an instance of an AF = behavior
aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered = aggregate
(OA). Packets in a flow DSCP-encoded with either = AF11/AF12/AF13 (for
example) are guaranteed to be transmitted in the = order received, but
will have different drop precedences (AF11 = highest; AF13 lowest). This
is usually achieved by serving all = packets on a port with the AF1* DSCP
via the same FIFO = queue.

No, this is not what I = mean. =46rom RFC2597:

In a DS node, the = level of forwarding assurance of an IP packet thus
depends on = (1) how much forwarding resources has been allocated to
the AF = class that the packet belongs to, (2) what is the current = load
of the AF class, and, in case of congestion within the = class, (3)
what is the drop precedence of the = packet.

So while AF PHB groups are indeed = meant to address such per-flow drop precedence, we still have a = per-aggregate function, meaning that it's risky business for an = application to decide that some of its packets have a higher drop = precedence (it might put the application at a disadvantage in comparison = with other *users*).

If you just look at page 4 = of http://tool= s.ietf.org/html/draft-lai-tsvwg-normalizer-02 (Flow A vs. Flow = B) you'll see an example that explains exactly the problem I'm talking = about. Indeed I think that this draft suggests a nice solution, but as = long as an application doesn't know that the mechanism in this draft is = in place everywhere, the incentive for an application to assign a higher = drop precedence to some packets still isn't = there.

For how I think this could be solved, = see my previous email to = Toerless.

Cheers,

Michael

= --Apple-Mail=_CB058D30-2927-4D5A-BBF1-1B50A1333569-- From csp@csperkins.org Tue Oct 15 03:19:47 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E555D21F9B66; Tue, 15 Oct 2013 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuP8ZTDaSUOk; Tue, 15 Oct 2013 03:19:47 -0700 (PDT) Received: from balrog.mythic-beasts.com (outgoingbounces2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000::13]) by ietfa.amsl.com (Postfix) with ESMTP id CF3F321F918C; Tue, 15 Oct 2013 03:19:43 -0700 (PDT) Received: from [130.209.247.112] (port=59203 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VW1iw-0004RJ-Ce; Tue, 15 Oct 2013 11:19:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: [rmcat] About the importance of packets in a single data stream From: Colin Perkins In-Reply-To: <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> Date: Tue, 15 Oct 2013 11:19:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:19:48 -0000 On 14 Oct 2013, at 12:15, Michael Welzl wrote: > On 14. okt. 2013, at 08:39, Toerless Eckert wrote: ... >> - How do you signal packet priority. DSCP is really ugly (TM). = Besides, its really ugly to set from application (TM). An RTP header = extension field would be IMHO much nicer. >=20 > I agree that DSCP is ugly; I was thinking that one would have to even = reserve bits in DSCP because, despite different priorities *within* a = connection, one might still apply e.g. DiffServ to differentiate between = 5-tuples. Indeed, given that this is functionality that's only meant for = devices that identify 5-tuples, something above IP would make sense. So = I think I agree that an RTP header extension would be a good choice. I strongly disagree. An RTP extension header is easy to add from the = application, but difficult to distinguish in the forwarding plane. The = semantics of the RTP header extension can only be inferred by looking at = the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we = want to tie the media path to the signalling path, nor should we require = routers to interact with the signalling protocol.=20 I also don't believe deep-packet inspection can usefully be used to find = the RTP header extension. Ignoring the layering violation, recall that = identifying RTP packets is difficult without keeping per-flow state, = that the header extension is at a variable offset into the RTP packet, = that multiple header extensions can be included in each RTP packet in an = arbitrary order, and that header extensions have a dynamically chosen = identifier mapped via the signalling channel with very little fixed text = to identify them. Plus, the RTP header extension may well be encrypted = if SRTP is used. Note also that RTCP, DTLS, or STUN packets are commonly multiplexed onto = the same 5-tuple, and don't have a corresponding header extension but = can use the DSCP field. I would assume we would want to be able to = assign a priority to those packets relative to the media.=20 If something in the UDP payload were considered appropriate to assign = per-packet priority, then I'd suggest that a shim-layer to identify = flows and priorities would be a better approach. That could add a couple = of bytes shim to each packet, to identify both flow priority and flow = type. This would also simplify some of the magic around demultiplexing = RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port = in many applications. We proposed a shim to address the de-multiplexing = part of this in draft-westerlund-avtcore-transport-multiplexing-06, and = although it doesn't address the per-packet priority, it would be = straight forward to add if it were desirable, and (unlike an RTP header = extension) could place the priority field at a fixed location in the = packet, with a well-known header to help identify the flows. --=20 Colin Perkins http://csperkins.org/ From michawe@ifi.uio.no Tue Oct 15 03:49:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C72C11E817D; Tue, 15 Oct 2013 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90T65D-l6yU6; Tue, 15 Oct 2013 03:48:57 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 23DD521F9A72; Tue, 15 Oct 2013 03:48:56 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VW2BK-0005eO-4m; Tue, 15 Oct 2013 12:48:54 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VW2BJ-0004cy-Jq; Tue, 15 Oct 2013 12:48:54 +0200 Subject: Re: [rmcat] About the importance of packets in a single data stream Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> Date: Tue, 15 Oct 2013 12:48:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23D31735-B93C-42B8-A1F7-116CEC3B7EA8@ifi.uio.no> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 8564 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D91616F292896ED3354DC15FC8655800A793909F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3342 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:49:07 -0000 On 15. okt. 2013, at 12:19, Colin Perkins wrote: > On 14 Oct 2013, at 12:15, Michael Welzl wrote: >> On 14. okt. 2013, at 08:39, Toerless Eckert wrote: > ... >>> - How do you signal packet priority. DSCP is really ugly (TM). = Besides, its really ugly to set from application (TM). An RTP header = extension field would be IMHO much nicer. >>=20 >> I agree that DSCP is ugly; I was thinking that one would have to even = reserve bits in DSCP because, despite different priorities *within* a = connection, one might still apply e.g. DiffServ to differentiate between = 5-tuples. Indeed, given that this is functionality that's only meant for = devices that identify 5-tuples, something above IP would make sense. So = I think I agree that an RTP header extension would be a good choice. >=20 >=20 > I strongly disagree. An RTP extension header is easy to add from the = application, but difficult to distinguish in the forwarding plane. The = semantics of the RTP header extension can only be inferred by looking at = the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we = want to tie the media path to the signalling path, nor should we require = routers to interact with the signalling protocol.=20 >=20 > I also don't believe deep-packet inspection can usefully be used to = find the RTP header extension. Ignoring the layering violation, recall = that identifying RTP packets is difficult without keeping per-flow = state, that the header extension is at a variable offset into the RTP = packet, that multiple header extensions can be included in each RTP = packet in an arbitrary order, and that header extensions have a = dynamically chosen identifier mapped via the signalling channel with = very little fixed text to identify them. Plus, the RTP header extension = may well be encrypted if SRTP is used. See, I don't know enough about RTP. Sorry... > Note also that RTCP, DTLS, or STUN packets are commonly multiplexed = onto the same 5-tuple, and don't have a corresponding header extension = but can use the DSCP field. I would assume we would want to be able to = assign a priority to those packets relative to the media.=20 >=20 > If something in the UDP payload were considered appropriate to assign = per-packet priority, then I'd suggest that a shim-layer to identify = flows and priorities would be a better approach. That could add a couple = of bytes shim to each packet, to identify both flow priority and flow = type. This would also simplify some of the magic around demultiplexing = RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port = in many applications. We proposed a shim to address the de-multiplexing = part of this in draft-westerlund-avtcore-transport-multiplexing-06, and = although it doesn't address the per-packet priority, it would be = straight forward to add if it were desirable, and (unlike an RTP header = extension) could place the priority field at a fixed location in the = packet, with a well-known header to help identify the flows. All of that makes sense to me. Cheers, Michael From eckert@cisco.com Tue Oct 15 09:34:30 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBA21E8161; Tue, 15 Oct 2013 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.636 X-Spam-Level: X-Spam-Status: No, score=-9.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6BLlmNvPJVL; Tue, 15 Oct 2013 09:34:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C84D921E815F; Tue, 15 Oct 2013 09:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1371; q=dns/txt; s=iport; t=1381854863; x=1383064463; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IJP634BLJeKiZWwC5Yv14Q+smsTtBHT1hPFuiX35rgw=; b=CLiinICfYJgI1vBk1SN8Zobcd+IlrGyjiDvwL/ekhzkMPivdG5JB2fbb qse10jMyvrolkw1pgHU3L0wp0aO4AynYeo6lO7SN3NpXLxD1TAKBjBUWE UjlyOQk2lZSpcFix+rTZ87+LRM0CuKscdOI0UIN8wuLki6j32mSZ+UZlo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAB1uXVKrRDoH/2dsb2JhbABagwc4wnuBIhZ0giUBAQEDATo/BQsLDgQGCSUPBTUUiBMFDb1Ij0oHgx+BBgOJPI5HAYEvkFODRBw X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="94716435" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 15 Oct 2013 16:34:06 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FGY5Be013257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 16:34:05 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9FGY55U020920; Tue, 15 Oct 2013 09:34:05 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9FGY59v020919; Tue, 15 Oct 2013 09:34:05 -0700 Date: Tue, 15 Oct 2013 09:34:05 -0700 From: Toerless Eckert To: Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream Message-ID: <20131015163405.GA20478@cisco.com> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <20131014143723.GB32524@cisco.com> <289D7CCD-0C73-4596-B6F0-053202C46BA2@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <289D7CCD-0C73-4596-B6F0-053202C46BA2@ifi.uio.no> User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:34:30 -0000 On Tue, Oct 15, 2013 at 10:06:32AM +0200, Michael Welzl wrote: > So now I finally read http://tools.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I like it a lot! It is indeed exactly what we need - but one issue with it is compatibility. Actually this could become a show-stopper, as this is all about getting the incentives right: why would my application ever set a higher drop precedence for some packets when I don't know if this normalizer is in place or not? And this decision would have to be taken by the application... if we wouldn't try to stadardize this behavior with DSCP marking but only with RTP markings then that definition could also include the clear requirement that network devices MUST NOT interpret these markings in a way that would penalize a flow against other flows with no or differnt markings. Aka: clear state that these are intra-flow priority markings and must be interpreted by the network as such. > I could imagine a scenario where an application inserts the RTP extension header that you mentioned, and then a flow-aware edge device which knows that this traffic is going to traverse a path where your normalization marker is in place marks packets into an AFx PHB group based on the RTP extension header. Then we have an architecture that is incentive-compatible AND scales. Right. Cheers Toerless From eckert@cisco.com Tue Oct 15 10:33:50 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53F411E8116; Tue, 15 Oct 2013 10:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WurzQ9kvHrE; Tue, 15 Oct 2013 10:33:45 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C063911E81A1; Tue, 15 Oct 2013 10:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3666; q=dns/txt; s=iport; t=1381858423; x=1383068023; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ryLIBbWxtVnbGIzZcfqy4kRL89ocIZyxR5KL9VkrKpU=; b=FacFBjDL0j8t58CmZEd8IY9w1Rv4e4NGcz3wJHHzA4RZuxtPKSDOjxdR rPOrgn9l1Rk5Ot4AcXdDdhq0qlZLim3zSKwnsdlQcZzbSmLb/Qm7YboIP xb7jHrenfzpz/qHd2ZabWOJ8BoQqP+U08LYlbo7kPBp4OaCp/sT4wdv7w 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAG17XVKrRDoH/2dsb2JhbABQCoMHwzSBIxZ0giUBAQEDAScTPwULCw4KCSUPBUmIEwW9eI4HgUMHgx+BBgOJPIprg1wBkgKDRBw X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="91489845" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Oct 2013 17:33:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FHXfR2020838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 17:33:42 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9FHXfUg023299; Tue, 15 Oct 2013 10:33:41 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9FHXfYG023298; Tue, 15 Oct 2013 10:33:41 -0700 Date: Tue, 15 Oct 2013 10:33:41 -0700 From: Toerless Eckert To: Colin Perkins Subject: Re: [rmcat] About the importance of packets in a single data stream Message-ID: <20131015173341.GB20478@cisco.com> References: <20131014063911.GA32524@cisco.com> <4C7D1B88-A3FE-4CA8-8228-DF4261DA73E1@ifi.uio.no> <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFF45A7-EB97-4794-8678-E157C47903D7@csperkins.org> User-Agent: Mutt/1.4.2.2i Cc: rmcat WG , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:33:50 -0000 On Tue, Oct 15, 2013 at 11:19:34AM +0100, Colin Perkins wrote: > I strongly disagree. An RTP extension header is easy to add from the application, but difficult to distinguish in the forwarding plane. The semantics of the RTP header extension can only be inferred by looking at the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we want to tie the media path to the signalling path, nor should we require routers to interact with the signalling protocol. Define RTP header extension with well-defined intra-flow priority field. Lets call it "Network-Signaling" RTP header extension. Might have other fields in it too beside priority (heck: even DSCP for poor apps that can't set it via their network stack ;-). Introduce new attribute to the STUN signaled metadata: draft-martinsen-mmusic-malice-00.txt. This attribute is signalled if the RTP packets on the 5-tuple have the network signaling RTP header extension, and its value is the ID of that RTP header extension. > I also don't believe deep-packet inspection can usefully be used to find the RTP header extension. Ignoring the layering violation, recall that identifying RTP packets is difficult without keeping per-flow state, that the header extension is at a variable offset into the RTP packet, that multiple header extensions can be included in each RTP packet in an arbitrary order, and that header extensions have a dynamically chosen identifier mapped via the signalling channel with very little fixed text to identify them. Plus, the RTP header extension may well be encrypted if SRTP is used. > > Note also that RTCP, DTLS, or STUN packets are commonly multiplexed onto the same 5-tuple, and don't have a corresponding header extension but can use the DSCP field. I would assume we would want to be able to assign a priority to those packets relative to the media. [Deleted rant about why we could not even design IPv6 so that useful new onpath header extensions could be placed in there ] I would hope the above proposed design answers those concerns of yours. -> Once the sender of the 5-tuple flow clear indicates to the network via STUN that the network-signaling header is present and what it's ID is, the routre/switches should have all they need. -> Obviously, the sender would not encrypt this paticular header as it specifically intends to signal its content to the network. -> Multiplexing should work fine because DPI in the network would use the sme simple rules to identify RTP vs. non-RTP packets in the flow, and then just find the RTP_header extension with the appropriate ID. > If something in the UDP payload were considered appropriate to assign per-packet priority, then I'd suggest that a shim-layer to identify flows and priorities would be a better approach. Sure. > That could add a couple of bytes shim to each packet, to identify both flow priority and flow type. This would also simplify some of the magic around demultiplexing RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port in many applications. We proposed a shim to address the de-multiplexing part of this in draft-westerlund-avtcore-transport-multiplexing-06, and although it doesn't address the per-packet priority, it would be straight forward to add if it were desirable, and (unlike an RTP header extension) could place the priority field at a fixed location in the packet, with a well-known header to help identify the flows. I like shim layer, but in the end the design that will succeeed is the one that apps most likely will adopt. How likely would RTCweb use shim-layer ? Cheers Toerless From michawe@ifi.uio.no Wed Oct 16 00:36:37 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1CF11E810F; Wed, 16 Oct 2013 00:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Etpx4AUZfdm0; Wed, 16 Oct 2013 00:36:32 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 3337211E810B; Wed, 16 Oct 2013 00:36:17 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VWLeK-0001vP-SD; Wed, 16 Oct 2013 09:36:08 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VWLeJ-0002P2-La; Wed, 16 Oct 2013 09:36:08 +0200 Subject: Re: [rmcat] About the importance of packets in a single data stream Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC" From: Michael Welzl In-Reply-To: Date: Wed, 16 Oct 2013 09:36:06 +0200 Message-Id: <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> To: Kevin Gross X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 3 sum rcpts/h 15 sum msgs/h 5 total rcpts 8620 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1136063B67F332C0EA27393680B552E9AED70268 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3363 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 07:36:37 -0000 --Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 [I'm adding tsv-area: I noticed it was dropped from some part of this = thread, but I think unintentionally? BTW I hope tsv-area is appropriate, = and not tsvwg? I started off to rmcat and tsv-area because I had a = general DiffServ'ish question, yet related to rmcat, and so I thought = this would fit.] Hi, Imagine that you write an application and based on the intra-flow = priorities of your packets you decide that this would be your profile: (copy+paste from the draft) *** Flow B 40% or 2Mbps in AF41 40% or 2Mbps in AF42 20% or 1Mbps in AF43 *** ...and the normalizer is not present in the network, and you get = "normal" DiffServ behavior (because we're using the standard AF = codepoints). Now, if someone else uses: *** Flow A 80% or 4Mbps in AF41 20% or 1Mbps in AF42 0% or 0Mbps in AF43 *** ...then this someone (flow A) would be better off in the presence of = congestion, as described in the draft. This means that you'll never = decide for a profile as in Flow B in your application because you could = hurt yourself, you might be treated worse than some other users. This is what the normalizer fixes, but as long as you don't know it's = there, going for a profile as in Flow B is still risky business. "You" in my story here is the application programmer, and it really has = to be the application programmer doing this - the priorities would be = derived from knowledge about the codec, FEC usage etc. What the = application programmer needs is a signal that is definitely going to be = ignored unless it hits a normalizing ingress device. Cheers, Michael On 16. okt. 2013, at 05:31, Kevin Gross wrote: > As I read it, the proposal in the draft is to have network equipment = tweak DSCP values at ingress points so that drop precedence proportions = are normalized in some way. This does not require that all senders = produce normalized streams. The only thing that needs to be accepted is = common normalization profiles for all the ingress points in the network. = Under the proposal, useful drop precedence behavior becomes a network = configuration issue, not a standards compliance issue. >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com >=20 >=20 > On Tue, Oct 15, 2013 at 8:13 PM, Toerless Eckert = wrote: > Partially true IMHO. >=20 > Yes, if we could have all flows agree to have a marking let's say 20% = high, > 60% normal and 20% low prio bits (long term average), then we would = not > need normalization. If there is any chance to establish such a = standard, that > would be gret. >=20 > It just doesn't change the problem of DSCP. It would change the PHB = though > by making it much more strict. Which makes it more questionable = whether it > would be accepted. >=20 >=20 > Cheers > Toerless >=20 >=20 > On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote: > > If we create a situation where all flows are "normalized" (i.e. a = certain > > percentage of their packets are marked with higher drop precedence) = by the > > network then we shouldn't have to deal with things on a per-flow = basis. If > > we're not dealing with things on a per-flow basis, we can use the = existing > > AF codepoints. Dropping according to drop precedence markings on a = class > > basis should be statistically fair to all flows so long as all flows = have > > been normalized. > > > > Kevin Gross > > +1-303-447-0517 > > Media Network Consultant > > AVA Networks - www.AVAnw.com > > > > > > On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert = wrote: > > > > > The method described in the draft is applicable to whatever = marking one > > > wants > > > to use. I wish DSCP was the solution because as you said it would = avoid > > > the need > > > for figuring out how to carry a new marking (like RTP header = extensions). > > > > > > But: There are no existing DSCP with the PHB of = "intra-flow-priority" with > > > a > > > guarantee that flows with different distributions of those = priorities > > > would see > > > the same percentage of drops under queue congestion. > > > > > > If we wanted to go the DSCP route, we would need at least 3 new = DSCP to > > > indicate > > > high,normal,low intra-flow priority (and just for intelligent = dropping, 3 > > > actually > > > might be good enough). But 3 new DSCP is an act of god in the = IETF. > > > > > > Then those three new DSCP would not only have to indicate = intra-flow > > > priority but > > > also the overall class PHB that the traffic should have even = without > > > priority > > > indications. Aka: lets say low loss, low latency, appropriate for = RMcat. > > > So when the next class of traffic with different intra-flow = priorities > > > comes > > > along, we'd have to redo the whole DSCP exercise again. And again. > > > > > > And then the DSCP still get reset along the path, and apps still = have > > > problems > > > setting DSCP across various OSs. > > > > > > Cheers > > > Toerless > > > > > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote: > > > > Maybe I skimmed it too quickly but my understanding is that the = proposal > > > is > > > > to remark DSCP values at the ingress point of the network and = possibly at > > > > other key boundaries too. Such DSCP remapping is already common = practice > > > in > > > > enterprise networks. > > > > > > > > The twist here is that the remapper will do the remapping = dynamically > > > based > > > > on the proportion of AFn1, AFn2 and AFn3 packets received from a = sender. > > > A > > > > greedy sender that it producing only AF41 markings will get some = of those > > > > randomly remarked as AF42 and AF43. > > > > > > > > The proposal uses existing DSCP values and it doesn't look like = signaling > > > > is necessary nor is it necessary for the application to know = that this is > > > > happening. > > > > > > > > Kevin Gross > > > > +1-303-447-0517 > > > > Media Network Consultant > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl = > > > wrote: > > > > > > > > > Hmm. Whether the balance is right or not might depend on how = the > > > signaling > > > > > is done. Anyway, unless I misunderstood something, the way the > > > normalizer > > > > > now stands it won't really make a change: it gives an = incentive to > > > > > applications to mark some packets with higher drop precedence, = yet > > > requires > > > > > applications to know that the normalizer is in place or else = the > > > service > > > > > would be different. > > > > > > > > > > Maybe different DSCP values would be needed - but then this = can't be > > > used > > > > > in combination with "regular" DiffServ usage. It really = depends on the > > > > > signaling - ideas are now being tossed around by Colin and = Toerless, > > > who > > > > > clearly both know more about what the right signaling could be = than me. > > > > > > > > > > Cheers, > > > > > Michael > > > > > > > > > > > > > > > On 15. okt. 2013, at 19:04, Kevin Gross = wrote: > > > > > > > > > > I think you're stretching here. I don't think the balance is = right. The > > > > > proposed information is difficult to retrieve and of little = use to > > > much of > > > > > the network. Even if standardized, it is unlikely to be = successful. > > > > > > > > > > The ideas in the normalizer draft don't seem to have so many = issues > > > and I > > > > > think it answers your original question and sets out to = achieve what > > > you're > > > > > looking for. > > > > > > > > > > Kevin Gross > > > > > +1-303-447-0517 > > > > > Media Network Consultant > > > > > AVA Networks - www.AVAnw.com > > > > > > > > > > > > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = > > > wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I'll dissect your second and third sentences and tell you = what I think > > > > >> about each part :-) below: > > > > >> > > > > >> > > > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote: > > > > >> > > > > >> > No, not per 5 tuple (per flow). I don't think that is = something we > > > > >> should ask of the network. > > > > >> > > > > >> I agree that asking this of the network may seem like = encouraging > > > > >> per-flow functionality; in particular, if we'd put this into = IP, that > > > would > > > > >> be ugly. However, it's just a matter of fact that there are = devices > > > that do > > > > >> identify flows, and then, why not give such devices some = guidance? I > > > like > > > > >> Toerless' suggestion of making this an RTP header extension = field: if > > > a > > > > >> device is identifying flows, we can expect such a device to = identify > > > such a > > > > >> field too. Plus, if we think of end systems playing an = intermediate > > > system > > > > >> role in RTP (mixers, ..), these devices might also benefit = from that > > > sort > > > > >> of information. > > > > >> > > > > >> > > > > >> > It doesn't sit well with the end-to-end principle > > > > >> > > > > >> I disagree, this is an all-too-common misunderstanding of the > > > end-to-end > > > > >> principle: it only says that whatever can be done in the = application > > > should > > > > >> be left up to the application, but it doesn't say that you = mustn't > > > identify > > > > >> application streams inside the network or "keep the network = simple and > > > > >> stupid". If you do "keep the network stupid", you're = definitely in > > > line > > > > >> with the e2e argument, but the argument isn't as strict as = that (a > > > typical > > > > >> example is routing, which can well become as complex as you = wish, > > > without > > > > >> harming the end-to-end principle). Now here we're discussing = a > > > function > > > > >> where the application really can't help you: when congestion = happens > > > inside > > > > >> the network and a packet must be dropped there, the best the > > > application > > > > >> can do is tell you which packet to drop. > > > > >> > > > > >> > > > > >> > and it won't scale. > > > > >> > > > > >> I agree. But it doesn't have to, just because we introduce = the signal > > > we > > > > >> don't harm scalability - devices at the edges of the network = could > > > deal > > > > >> with it, all other devices could ignore it. > > > > >> > > > > >> Cheers, > > > > >> Michael > > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > --- > > > Toerless Eckert, eckert@cisco.com > > > Cisco NSSTG Systems & Technology Architecture > > > SDN: Let me play with the network, mommy! > > > > > > >=20 > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 >=20 --Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

***
= Flow A

80% or = 4Mbps in AF41

= 20% or 1Mbps in AF42

= 0% or 0Mbps in = AF43
***

...then this someone (flow = A) would be better off in the presence of congestion, as described in = the draft. This means that you'll never decide for a profile as in Flow = B in your application because you could hurt yourself, you might be = treated worse than some other users.

This is = what the normalizer fixes, but as long as you don't know it's there, = going for a profile as in Flow B is still risky = business.

"You" in my story here is the = application programmer, and it really has to be the application = programmer doing this - the priorities would be derived from knowledge = about the codec, FEC usage etc. What the application programmer needs is = a signal that is definitely going to be ignored unless it hits a = normalizing ingress = device.

Cheers,
Michael
=

On 16. okt. 2013, at 05:31, = Kevin Gross wrote:

As I read it, the proposal in the draft is to have network = equipment tweak DSCP values at ingress points so that drop precedence = proportions are normalized in some way. This does not require that all = senders produce normalized streams. The only thing that needs to be = accepted is common normalization profiles for all the ingress points in = the network. Under the proposal, useful drop precedence behavior becomes = a network configuration issue, not a standards compliance issue.

Kevin = Gross
+1-303-447-0517
Media Network = Consultant
AVA Networks - www.AVAnw.com

On Tue, Oct 15, 2013 at 8:13 PM, = Toerless Eckert <eckert@cisco.com> wrote:
Partially true IMHO.

Yes, if we could have all flows agree to have a marking let's say 20% = high,
60% normal and 20% low prio bits (long term average), then we would = not
need normalization. If there is any chance to establish such a standard, = that
would be gret.

It just doesn't change the problem of DSCP. It would change the PHB = though
by making it much more strict. Which makes it more questionable whether = it
would be accepted.

Cheers
= Toerless

On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote:
> If we create a situation where all flows are "normalized" (i.e. a = certain
> percentage of their packets are marked with higher drop precedence) = by the
> network then we shouldn't have to deal with things on a per-flow = basis. If
> we're not dealing with things on a per-flow basis, we can use the = existing
> AF codepoints. Dropping according to drop precedence markings on a = class
> basis should be statistically fair to all flows so long as all = flows have
> been normalized.
>
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant

> AVA Networks - www.AVAnw.com = <http://www.avanw.com/>
>
>
> On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert <eckert@cisco.com> wrote:
>
> > The method described in the draft is applicable to whatever = marking one
> > wants
> > to use. I wish DSCP was the solution because as you said it = would avoid
> > the need
> > for figuring out how to carry a new marking (like RTP header = extensions).
> >
> > But: There are no existing DSCP with the PHB of = "intra-flow-priority" with
> > a
> > guarantee that flows with different distributions of those = priorities
> > would see
> > the same percentage of drops under queue congestion.
> >
> > If we wanted to go the DSCP route, we would need at least 3 = new DSCP to
> > indicate
> > high,normal,low intra-flow priority (and just for intelligent = dropping, 3
> > actually
> > might be good enough). But 3 new DSCP is an act of god in the = IETF.
> >
> > Then those three new DSCP would not only have to indicate = intra-flow
> > priority but
> > also the overall class PHB that the traffic should have even = without
> > priority
> > indications. Aka: lets say low loss, low latency, appropriate = for RMcat.
> > So when the next class of traffic with different intra-flow = priorities
> > comes
> > along, we'd have to redo the whole DSCP exercise again. And = again.
> >
> > And then the DSCP still get reset along the path, and apps = still have
> > problems
> > setting DSCP across various OSs.
> >
> > Cheers
> > Toerless
> >
> > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross = wrote:
> > > Maybe I skimmed it too quickly but my understanding is = that the proposal
> > is
> > > to remark DSCP values at the ingress point of the network = and possibly at
> > > other key boundaries too. Such DSCP remapping is already = common practice
> > in
> > > enterprise networks.
> > >
> > > The twist here is that the remapper will do the remapping = dynamically
> > based
> > > on the proportion of AFn1, AFn2 and AFn3 packets received = from a sender.
> > A
> > > greedy sender that it producing only AF41 markings will = get some of those
> > > randomly remarked as AF42 and AF43.
> > >
> > > The proposal uses existing DSCP values and it doesn't = look like signaling
> > > is necessary nor is it necessary for the application to = know that this is
> > > happening.
> > >
> > > Kevin Gross
> > > +1-303-447-0517
> > > Media Network Consultant
> > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > >
> > >
> > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl <michawe@ifi.uio.no>
> > wrote:
> > >
> > > > Hmm. Whether the balance is right or not might = depend on how the
> > signaling
> > > > is done. Anyway, unless I misunderstood something, = the way the
> > normalizer
> > > > now stands it won't really make a change: it gives = an incentive to
> > > > applications to mark some packets with higher drop = precedence, yet
> > requires
> > > > applications to know that the normalizer is in place = or else the
> > service
> > > > would be different.
> > > >
> > > > Maybe different DSCP values would be needed - but = then this can't be
> > used
> > > > in combination with "regular" DiffServ usage. It = really depends on the
> > > > signaling - ideas are now being tossed around by = Colin and Toerless,
> > who
> > > > clearly both know more about what the right = signaling could be than me.
> > > >
> > > > Cheers,
> > > > Michael
> > > >
> > > >
> > > > On 15. okt. 2013, at 19:04, Kevin Gross <kevin.gross@avanw.com> = wrote:
> > > >
> > > > I think you're stretching here. I don't think the = balance is right. The
> > > > proposed information is difficult to retrieve and of = little use to
> > much of
> > > > the network. Even if standardized, it is unlikely to = be successful.
> > > >
> > > > The ideas in the normalizer draft don't seem to have = so many issues
> > and I
> > > > think it answers your original question and sets out = to achieve what
> > you're
> > > > looking for.
> > > >
> > > > Kevin Gross
> > > > +1-303-447-0517
> > > > Media Network Consultant
> > > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > > >
> > > >
> > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl = <michawe@ifi.uio.no>
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'll dissect your second and third sentences and = tell you what I think
> > > >> about each part :-) below:
> > > >>
> > > >>
> > > >> On 14. okt. 2013, at 23:35, Kevin Gross = wrote:
> > > >>
> > > >> > No, not per 5 tuple (per flow). I don't = think that is something we
> > > >> should ask of the network.
> > > >>
> > > >> I agree that asking this of the network may seem = like encouraging
> > > >> per-flow functionality; in particular, if we'd = put this into IP, that
> > would
> > > >> be ugly. However, it's just a matter of fact = that there are devices
> > that do
> > > >> identify flows, and then, why not give such = devices some guidance? I
> > like
> > > >> Toerless' suggestion of making this an RTP = header extension field: if
> > a
> > > >> device is identifying flows, we can expect such = a device to identify
> > such a
> > > >> field too. Plus, if we think of end systems = playing an intermediate
> > system
> > > >> role in RTP (mixers, ..), these devices might = also benefit from that
> > sort
> > > >> of information.
> > > >>
> > > >>
> > > >> > It doesn't sit well with the end-to-end = principle
> > > >>
> > > >> I disagree, this is an all-too-common = misunderstanding of the
> > end-to-end
> > > >> principle: it only says that whatever can be = done in the application
> > should
> > > >> be left up to the application, but it doesn't = say that you mustn't
> > identify
> > > >> application streams inside the network or "keep = the network simple and
> > > >> stupid". If you do "keep the network stupid", = you're definitely in
> > line
> > > >> with the e2e argument, but the argument isn't as = strict as that (a
> > typical
> > > >> example is routing, which can well become as = complex as you wish,
> > without
> > > >> harming the end-to-end principle). Now here = we're discussing a
> > function
> > > >> where the application really can't help you: = when congestion happens
> > inside
> > > >> the network and a packet must be dropped there, = the best the
> > application
> > > >> can do is tell you which packet to drop.
> > > >>
> > > >>
> > > >> > and it won't scale.
> > > >>
> > > >> I agree. But it doesn't have to, just because we = introduce the signal
> > we
> > > >> don't harm scalability - devices at the edges of = the network could
> > deal
> > > >> with it, all other devices could ignore it.
> > > >>
> > > >> Cheers,
> > > >> Michael
> > > >>
> > > >>
> > > >
> > > >
> >
> > --
> > ---
> > Toerless Eckert, eckert@cisco.com
> > Cisco NSSTG Systems & Technology Architecture
> > SDN: Let me play with the network, mommy!
> >
> >

--
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

= --Apple-Mail=_DE58D3AC-4F90-431D-95C7-97CA61F043DC-- From roland.bless@kit.edu Wed Oct 16 01:22:33 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D506B21F9A6A; Wed, 16 Oct 2013 01:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKNZAQSBYNqL; Wed, 16 Oct 2013 01:22:25 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 893AF21F9E7E; Wed, 16 Oct 2013 01:21:53 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1VWMML-0004vz-Ju; Wed, 16 Oct 2013 10:21:41 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 611ACA80445; Wed, 16 Oct 2013 10:21:42 +0200 (CEST) Message-ID: <525E4C96.2010102@kit.edu> Date: Wed, 16 Oct 2013 10:21:42 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Michael Welzl , Kevin Gross Subject: Re: [rmcat] About the importance of packets in a single data stream References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> In-Reply-To: <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1381911701. Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:22:33 -0000 Hi Michael, On 16.10.2013 09:36, Michael Welzl wrote: > [I'm adding tsv-area: I noticed it was dropped from some part of this > thread, but I think unintentionally? BTW I hope tsv-area is appropriate, > and not tsvwg? I started off to rmcat and tsv-area because I had a > general DiffServ'ish question, yet related to rmcat, and so I thought > this would fit.] Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat yet. > ...then this someone (flow A) would be better off in the presence of > congestion, as described in the draft. This means that you'll never > decide for a profile as in Flow B in your application because you could > hurt yourself, you might be treated worse than some other users. > > This is what the normalizer fixes, but as long as you don't know it's > there, going for a profile as in Flow B is still risky business. > > "You" in my story here is the application programmer, and it really has > to be the application programmer doing this - the priorities would be > derived from knowledge about the codec, FEC usage etc. What the > application programmer needs is a signal that is definitely going to be > ignored unless it hits a normalizing ingress device. Just some few observations from my point of view: - DiffServ doesn't distinguish between individual flows within a behavior aggregate - it was intentionally designed that way. Per micro-flow unfairness within the same class is not prevented by DiffServ - conceptionally you should only use the first-hop router for this kind of traffic conditioning measures. However, this doesn't help to prevent other aggregation effects inside a DiffServ domain (cf. Per-Hop Behavior vs. Per Domain Behavior). - Following the end-to-end argument, it doesn't make sense to build somewhat complex mechanisms into the network, which may even depend on the particular application (like WebRTC etc.) - so building a "normalizer" (w/o having fully understood the concept) into the network doesn't seem to be the right approach in the long run. - Therefore, I agree very much with your last statement: it's only the application that has the knowledge and context to set any kind of forwarding priority (or drop precendence) for individual packets correctly. Especially, the logic to react on dropped packets should reflect the marking and corresponding dropping behavior. Regards, Roland From michawe@ifi.uio.no Wed Oct 16 01:49:20 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9135E11E8167; Wed, 16 Oct 2013 01:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwKNn1T3leXk; Wed, 16 Oct 2013 01:49:16 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 6369C11E811B; Wed, 16 Oct 2013 01:49:15 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VWMmu-0004LA-N7; Wed, 16 Oct 2013 10:49:04 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VWMmt-0001Wh-Tw; Wed, 16 Oct 2013 10:49:04 +0200 Subject: Re: [rmcat] About the importance of packets in a single data stream Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F" From: Michael Welzl In-Reply-To: <525E4C96.2010102@kit.edu> Date: Wed, 16 Oct 2013 10:49:02 +0200 Message-Id: References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> <525E4C96.2010102@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 15 sum msgs/h 6 total rcpts 8630 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A1829A9EEAA0737530720645FBC6E37697756E8B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3369 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org, Kevin Gross X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:49:20 -0000 --Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 16. okt. 2013, at 10:21, Bless, Roland (TM) wrote: > Hi Michael, >=20 > On 16.10.2013 09:36, Michael Welzl wrote: >> [I'm adding tsv-area: I noticed it was dropped from some part of this >> thread, but I think unintentionally? BTW I hope tsv-area is = appropriate, >> and not tsvwg? I started off to rmcat and tsv-area because I had a >> general DiffServ'ish question, yet related to rmcat, and so I thought >> this would fit.] >=20 > Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat = yet. ... and dropping tsv-area was a mistake, as your message shows :( = 'cause we've been around this block I think... >> ...then this someone (flow A) would be better off in the presence of >> congestion, as described in the draft. This means that you'll never >> decide for a profile as in Flow B in your application because you = could >> hurt yourself, you might be treated worse than some other users. >>=20 >> This is what the normalizer fixes, but as long as you don't know it's >> there, going for a profile as in Flow B is still risky business. >>=20 >> "You" in my story here is the application programmer, and it really = has >> to be the application programmer doing this - the priorities would be >> derived from knowledge about the codec, FEC usage etc. What the >> application programmer needs is a signal that is definitely going to = be >> ignored unless it hits a normalizing ingress device. >=20 > Just some few observations from my point of view: > - DiffServ doesn't distinguish between individual flows within > a behavior aggregate - it was intentionally designed that way. > Per micro-flow unfairness within the same class is not prevented > by DiffServ - conceptionally you should only use the first-hop router > for this kind of traffic conditioning measures. However, this doesn't > help to prevent other aggregation effects inside a DiffServ domain > (cf. Per-Hop Behavior vs. Per Domain Behavior). Sure- > - Following the end-to-end argument, it doesn't make sense to build > somewhat complex mechanisms into the network, which may even depend > on the particular application (like WebRTC etc.) - so building a > "normalizer" (w/o having fully understood the concept) into the > network doesn't seem to be the right approach in the long run. I disagree with what you say about e2e, see: http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html but anyway that's a separate debate, as the normalizer draft works on = aggregates and is really compliant with DiffServ as far as I can tell. That's the draft we're debating here: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 > - Therefore, I agree very much with your last statement: it's only > the application that has the knowledge and context to set any > kind of forwarding priority (or drop precendence) for individual > packets correctly. > Especially, the logic to react on dropped packets should reflect > the marking and corresponding dropping behavior. Yeah, the issue we're debating is that an application won't have an = incentive to go for the profile of Flow B (page 4 of the draft) unless = it knows that the normalizer is there, because otherwise it could get = treated in the normal DiffServ way and that would make it worse off than = Flow A (page 4 of the draft). Thus you need a way for the application to = signal intra-flow packet priorities to an edge without "standard = DiffServ" operating on that signal. The signal must be ignored unless = the normalizer is there. I hope that helped to clarify the discussion a bit... Cheers, Michael --Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Michael,

On 16.10.2013 09:36, Michael Welzl = wrote:
[I'm adding tsv-area: I noticed it = was dropped from some part of this
thread, but I think unintentionally? BTW I hope tsv-area = is appropriate,
and not tsvwg? = I started off to rmcat and tsv-area because I had = a
general DiffServ'ish = question, yet related to rmcat, and so I = thought
this would = fit.]

Yes, I'm following this on TSVAREA since I'm = not subscribed on rmcat yet.

... = and dropping tsv-area was a mistake, as your message shows :( = 'cause we've been around this block I = think...

...then this someone (flow = A) would be better off in the presence of
congestion, as described in the draft. This means that = you'll never
decide for a = profile as in Flow B in your application because you = could
hurt yourself, you might = be treated worse than some other users.

This is what = the normalizer fixes, but as long as you don't know = it's
there, going for a = profile as in Flow B is still risky = business.

"You" in my = story here is the application programmer, and it really = has
to be the application = programmer doing this - the priorities would = be
derived from knowledge = about the codec, FEC usage etc. What the
application programmer needs is a signal that is = definitely going to be
ignored = unless it hits a normalizing ingress device.

Just = some few observations from my point of view:
- DiffServ doesn't = distinguish between individual flows within
a behavior = aggregate - it was intentionally designed that way.
Per = micro-flow unfairness within the same class is not prevented
= by DiffServ - conceptionally you should only use the first-hop = router
for this kind of traffic conditioning measures. = However, this doesn't
help to prevent other aggregation = effects inside a DiffServ domain
(cf. Per-Hop Behavior vs. Per = Domain = Behavior).

Sure-

=

- Following the end-to-end = argument, it doesn't make sense to build
somewhat complex = mechanisms into the network, which may even depend
on the = particular application (like WebRTC etc.) - so building a
= "normalizer" (w/o having fully understood the concept) into = the
network doesn't seem to be the right approach in the long = run.

I disagree with what you = say about e2e, see:
= http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html
=
but anyway that's a separate debate, as the normalizer draft works = on aggregates and is really compliant with DiffServ as far as I can = tell.
That's the draft we're debating here:
http://t= ools.ietf.org/html/draft-lai-tsvwg-normalizer-02

<= div>

- Therefore, I agree = very much with your last statement: it's only
the application = that has the knowledge and context to set any
kind of = forwarding priority (or drop precendence) for individual
= packets correctly.
Especially, the logic to react on = dropped packets should reflect
the marking and corresponding = dropping behavior.

Yeah, the = issue we're debating is that an application won't have an incentive to = go for the profile of Flow B (page 4 of the draft) unless it knows that = the normalizer is there, because otherwise it could get treated in the = normal DiffServ way and that would make it worse off than Flow A (page 4 = of the draft). Thus you need a way for the application to signal = intra-flow packet priorities to an edge without "standard DiffServ" = operating on that signal. The signal must be ignored unless the = normalizer is there.

I hope that helped to clarify = the discussion a = bit...

Cheers,
Michael

= --Apple-Mail=_AA588AFE-C7D5-4736-8F64-81CCBFDC918F-- From roland.bless@kit.edu Wed Oct 16 12:43:35 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A56F11E82B0; Wed, 16 Oct 2013 12:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPYrHkj3SjdS; Wed, 16 Oct 2013 12:43:30 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2B11E81DB; Wed, 16 Oct 2013 12:43:23 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1VWWzv-00061q-HU; Wed, 16 Oct 2013 21:43:13 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 0F70BA806BD; Wed, 16 Oct 2013 21:43:17 +0200 (CEST) Message-ID: <525EEC54.7050003@kit.edu> Date: Wed, 16 Oct 2013 21:43:16 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Michael Welzl Subject: Re: [rmcat] About the importance of packets in a single data stream References: <700D2DE2-4ADD-4691-9921-DD0662C9B8E2@ifi.uio.no> <91BE54D0-A6B1-458E-A3B9-F2354B723CFE@ifi.uio.no> <20131016002302.GC20478@cisco.com> <20131016021324.GA11683@cisco.com> <954D14F0-981A-490E-9432-7B2B04E8E618@ifi.uio.no> <525E4C96.2010102@kit.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1381952594. Cc: Bernard Aboba , rmcat WG , tsv-area@ietf.org, Kevin Gross X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:43:35 -0000 Hi Michael and all, Am 16.10.2013 10:49, schrieb Michael Welzl: >> - Following the end-to-end argument, it doesn't make sense to build >> somewhat complex mechanisms into the network, which may even depend >> on the particular application (like WebRTC etc.) - so building a >> "normalizer" (w/o having fully understood the concept) into the >> network doesn't seem to be the right approach in the long run. > > I disagree with what you say about e2e, see: > http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html > but anyway that's a separate debate, as the normalizer draft works on > aggregates and is really compliant with DiffServ as far as I can tell. > That's the draft we're debating here: > http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 Thanks for the pointer, I quickly read over it. My understanding is: if we have an example flow of AF41:AF42:AF43 80:20:0 the normalizer would reassign those packets to 40:20:20 (or whatever the configured proportion is). Is this perception correct? Regarding the e2e argument: - you said "it only says that whatever can be done in the application should be left up to the application" - I don't think this catches the gist of it: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible". => especially, application knowledge is often required when reacting on failures, i.e., the right decision cannot be made when implemented within the network. Thus, dropping packets according to the markings set by the application is fully in accordance with the e2e argument, whereas building marking mechanisms into the network that require application knowledge is usually not in accordance with it. - if I understood the normalizer proposal in draft-lai-tsvwg-normalizer-02 correctly, it is not in line with the e2e argument since it reassigns drop precedences without application knowledge. Thus, it may make the wrong decisions about the importance of packets, not knowing how apps react to loss. >> - Therefore, I agree very much with your last statement: it's only >> the application that has the knowledge and context to set any >> kind of forwarding priority (or drop precendence) for individual >> packets correctly. >> Especially, the logic to react on dropped packets should reflect >> the marking and corresponding dropping behavior. > > Yeah, the issue we're debating is that an application won't have an > incentive to go for the profile of Flow B (page 4 of the draft) unless > it knows that the normalizer is there, because otherwise it could get > treated in the normal DiffServ way and that would make it worse off than > Flow A (page 4 of the draft). Thus you need a way for the application to > signal intra-flow packet priorities to an edge without "standard > DiffServ" operating on that signal. The signal must be ignored unless > the normalizer is there. > > I hope that helped to clarify the discussion a bit... Thanks, I think I understand the rationale now. However, I see several potential problems with this approach and have some thoughts to share as well: 0) I think an application with a 40:20:20 assignment has no real problem if it experiences loss in PHBs AFx2, AFx3 since it was designed that way. Whether it's "unfair" w.r.t. to other streams doesn't really matter. Remember that QoS support is usually managed unfairness anyway. Fairness within AF usually matters for the "yellow" packets, e.g., AFx2. This excess bandwidth should be fairly shared among all streams in this AF class if possible. 1) reassignment of drop precedences w/o application knowledge 2) how can one find the right default proportions suitable for different streams or applications? 3) Is this AF PHB class restricted to forward this special kind of encoded video streams? If so, we already have the problem of knowing that this is actually the case in the particular DS domain/region... 4) Normalizing other (non video) streams within the same AF class may cause adverse effects to the application behavior. 5) Aggregation effects within a domain in interior nodes may cause a different proportion than what the normalizer is configured for. Thus the normalizer may not cause the desired effects for a whole domain. 6) The AF PHB group per se is difficult to handle, since drop precedences may be even inconsistenly configured within a DS domain or DS region (see RFC 2597, sec. 4 at the end: "Inconsistent discard behaviors lead to inconsistent end-to-end service semantics and limit the range of possible uses of the AF PHB in a multi-vendor environment."). Furthermore, packets of lowest drop precedence may suffer from packets with higher drop precedences waiting before them in the queue. 7) For an AF class you basically need a sort of admission control for the assured (let's say "green") AFx1 packets to guarantee the low loss probability. Every usage of excess bandwidth is purely optional for which the application must be prepared. Regards, Roland From mls.ietf@gmail.com Thu Oct 17 08:50:43 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A009E11E8271 for ; Thu, 17 Oct 2013 08:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su0V8hjN+6ZC for ; Thu, 17 Oct 2013 08:50:24 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95811E8244 for ; Thu, 17 Oct 2013 08:50:23 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id d49so1169205eek.20 for ; Thu, 17 Oct 2013 08:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yEUg9PPZ8x+mLdhMcg6QtsN2rsM9mN0hY2gPQRP2uzI=; b=S4jq9ZmyxaMfp0mNIGAB8rYlQiA4+Kr/by8K+iEY4tnBU/uXWwAGx9P4oSZuu58xxY 0XfAFpwcEdbrkm8wbUeGJV/+zcc4MkIMto1SATFTShXBUP83sbPulfgmfYh4ej/88rn+ hu/2O4J1NBJfBpR52g7Sh8Q/IvtUvvP+o8Ik2qgRN3iaFd3QRJFIvsIhc9+ealUXLFMX EFMGkLEPhRa1aqDJAQkIBX/7TEPDCW5C9SjL3K1OEkaNAJuePaICnv7aTzlRjd7Xx4JH KQ9p1uiA0IvtYU401CzqI/VJ2tYhrGvFuyImCSyQ4fYwd9PMDIjR0RWxh4qdikOEakFF THiA== X-Received: by 10.15.22.2 with SMTP id e2mr2777934eeu.89.1382025023296; Thu, 17 Oct 2013 08:50:23 -0700 (PDT) Received: from [0.0.0.0] ([2001:1a80:2801:2d00:eca2:698d:373a:2fb5]) by mx.google.com with ESMTPSA id i1sm194376110eeg.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 08:50:22 -0700 (PDT) Message-ID: <52600724.7020607@gmail.com> Date: Thu, 17 Oct 2013 17:49:56 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: Fwd: NOMCOM - Critical shortage of nominees for multiple areas References: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> In-Reply-To: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:50:44 -0000 Please consider if you want to nominated somebody or yourself. Thanks, Martin -------- Original Message -------- Subject: NOMCOM - Critical shortage of nominees for multiple areas Date: Thu, 17 Oct 2013 07:24:34 -0700 From: NomCom Chair 2013 Reply-To: ietf@ietf.org, Nomcom@ietfa.amsl.com, Chair@ietfa.amsl.com, "2013 CC: IETF Discuss [Catchier Subject line - apologies to those offended by a duplicate] A critically low number of people have accepted nominations for some of the IESG open positions. There is only one nominee per slot in APP, OPS and TSV, only two in INT and RAI. Many folks have declined nominations. While the Nomcom appreciates that support for two years of intense service is hard to assure, and while we are aware that there is much support for the incumbents who are standing, the IETF should continually be considering which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation. Therefore, we urgently request that more nominees come forward. DEADLINES Nominations - October 18 Questionnaires from nominees - October 25 Not coincidentally, this is a good time to think over and send your comments about the current statements of desired expertise of positions - this is part of the Nomcom's annual review process as well. Send them to nomcom13@ietf.org. Definitive location [*] of the current statements on desired expertise: https://datatracker.ietf.org/nomcom/2013/expertise/ Instructions and details on nomination [**]: https://datatracker.ietf.org/ann/nomcom/60602/ Thanks, everyone, Allison for the Nomcom [*] This year the Nomcom tools were recoded, and also transitioned into the datatracker. Apologies for a number of places where we didn't catch reference errors. [**] Yes, alas, the previous call for nominations used "OAM" instead of "OPS," but we have* corrected this (chair's pilot) error where it occurred in the Nomcom pages. From mls.ietf@gmail.com Wed Oct 23 00:12:54 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B551611E816D for ; Wed, 23 Oct 2013 00:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l47Zt0who9x3 for ; Wed, 23 Oct 2013 00:12:54 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C7B8811E8166 for ; Wed, 23 Oct 2013 00:12:52 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so180565ead.17 for ; Wed, 23 Oct 2013 00:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=sVXr2YbLt2loJIniNBR2Jt0wQ2xKHsbnegcf1crLo9g=; b=eYd2NMzJuiH6jWJLMuaciNCINzTCI9hFivtFZKFkarYSZGcgAxMLzlCZyLdGugNMp7 kJ+xZ9HKhrvbjV3RUoYHaZ/siyQ/+kD1okA2eWDwK6PazSldcbEWIITHGDmr1101qqw4 SKcRxwHeDcDawAPcf0eC40np+yuvoezbewNXCycXEUVHaVtiMI5si8sBU9EU7sdqh9HZ opNQ5n+/vV8fH9GouFHijQg4wnkpQV9+43qDf4K3hiC/z3A/Xh6YiMoRZlm3PxWjtdZi Gqk0t0VAzIP1DfpybwdS0qwH6EXdEyQaYKdG8u1z0UyqgoMJ8GPP4STAdOpK4Ea6ovNG ZU0A== X-Received: by 10.14.45.70 with SMTP id o46mr106410eeb.19.1382512371977; Wed, 23 Oct 2013 00:12:51 -0700 (PDT) Received: from ?IPv6:2001:1a80:2801:3c00:48c2:7f46:4a1d:38ee? ([2001:1a80:2801:3c00:48c2:7f46:4a1d:38ee]) by mx.google.com with ESMTPSA id d7sm1960820eem.8.2013.10.23.00.12.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 00:12:51 -0700 (PDT) Message-ID: <526776F0.50401@gmail.com> Date: Wed, 23 Oct 2013 09:12:48 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 07:12:54 -0000 Dear all, We would like to give time to the Transport Area to discuss any potential need to evolve the IETF transport protocols. There are a number of proposals discussed in the IETF and outside of the IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. QUIC [3]), and also discussions about the congestion control approach to be used (e.g., delay-based [4], LEDBAT [5]). (We are fully aware that this list of proposals is incomplete) Spencer and I are planning a slot in the TSVAREA session at IETF 88 in Vancouver to discuss this topic. More information to come soon. Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested in contributing actively to the session. Thanks, Spencer and Martin, your TSV ADs. References [1] https://developers.google.com/speed/protocols/tcp-laminar [2] http://tools.ietf.org/html/draft-iyengar-minion-concept [3] https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?pli=1 [4] https://datatracker.ietf.org/wg/rmcat/charter/ [5] https://datatracker.ietf.org/wg/ledbat/charter/ From mls.ietf@gmail.com Wed Oct 23 03:48:58 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8211E834F for ; Wed, 23 Oct 2013 03:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZT+qARQPAOs for ; Wed, 23 Oct 2013 03:48:57 -0700 (PDT) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF911E819A for ; Wed, 23 Oct 2013 03:48:56 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id c50so370637eek.18 for ; Wed, 23 Oct 2013 03:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=rMMqnl3M9jLDeSs6M2eJOEHm/t9gCSY2zUFhAExNdFo=; b=tU2J2HbxOp6MLnNAEAkMbBdj5cEgBbrbei7qMu5CLWyEteLGt0SrbEd1Nko1mVe9ts 8D6/bbiNhkgkgalWvqzwlXcfu3INCX6wZsKgYaDh7qMofGMp5+zxafOTQ2XeP9wdTaj2 NvFb7x578IjS95Zn/dooWBfCUzn0DejqGw/jmLXU367d/QBhmGOlLiPxjv1OKfypc0rf Zy+MfD1navE1MLGTDFmIqFkyp8JlNhnnAjuypnVl7hrM/vQ1U2O9bRvB3ly3kpfq4JvU zmBLTauwNSW/z//26CBXrzhcyLTOF+Q2svzD9ut30U9kyH+ms6TKNhbvAx2K7WFYHaVI JHZw== X-Received: by 10.15.111.202 with SMTP id cj50mr1054646eeb.71.1382525335580; Wed, 23 Oct 2013 03:48:55 -0700 (PDT) Received: from ?IPv6:2001:1a80:2801:3c00:981d:7c30:f9:ed9b? ([2001:1a80:2801:3c00:981d:7c30:f9:ed9b]) by mx.google.com with ESMTPSA id k7sm68513115eeg.13.2013.10.23.03.48.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 03:48:54 -0700 (PDT) Message-ID: <5267A98E.5030902@gmail.com> Date: Wed, 23 Oct 2013 12:48:46 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: Draft agenda for the IETF-88 Transport Area Open Meeting (TSVAREA) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:48:58 -0000 Hi all, Please find below the draft agenda for the Transport Area Open Meeting (TSVAREA). The always up to date agenda is availabe here: http://www.ietf.org/proceedings/88/agenda/agenda-88-tsvarea Draft agenda for the Transport Area Open Meeting (TSVAREA) IETF-88, Vancouver THURSDAY, November 7, 2013 0900-1130 PST Responsible ADs: Spencer Dawkins Martin Stiemerling Mailing list: tsv-area@ietf.org Draft agenda: - Note Well and agenda bashing (5 minutes) - Latency workshop report (15 mins + 5 mins Q&A) Mat Ford -- http://www.internetsociety.org/latency2013 - Evolution of IETF Transport Protocols (60 mins) -- http://www.ietf.org/mail-archive/web/tsv-area/current/msg00973.html - Google QUIC protocol (30 mins + 10 mins Q&A) Jim Roskind - Re-thinking ECN (20 + 5 mins) Bob Briscoe From wes@mti-systems.com Wed Oct 23 07:55:11 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84C11E81B1 for ; Wed, 23 Oct 2013 07:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFS5zPMqOuH1 for ; Wed, 23 Oct 2013 07:55:06 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6900B11E838F for ; Wed, 23 Oct 2013 07:55:06 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9NEsw9W015446 for ; Wed, 23 Oct 2013 10:54:58 -0400 Received: (qmail 17679 invoked by uid 0); 23 Oct 2013 14:54:58 -0000 X-TCPREMOTEIP: 107.45.66.21 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.66.21) by 0 with ESMTPA; 23 Oct 2013 14:54:57 -0000 Message-ID: <5267E307.6000200@mti-systems.com> Date: Wed, 23 Oct 2013 10:53:59 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , tsv-area@ietf.org Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> In-Reply-To: <526776F0.50401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:55:11 -0000 On 10/23/2013 3:12 AM, Martin Stiemerling wrote: > Dear all, > > We would like to give time to the Transport Area to discuss any > potential need to evolve the IETF transport protocols. > > There are a number of proposals discussed in the IETF and outside of the > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > QUIC [3]), and also discussions about the congestion control approach to > be used (e.g., delay-based [4], LEDBAT [5]). > > (We are fully aware that this list of proposals is incomplete) > One other protocol that has been floating around outside the IETF for awhile is Saratoga, though we've talked about it a little in TSVWG and there are a number of internet-drafts: http://datatracker.ietf.org/doc/draft-wood-tsvwg-saratoga/ http://datatracker.ietf.org/doc/draft-wood-tsvwg-saratoga-congestion-control/ http://datatracker.ietf.org/doc/draft-eddy-tsvwg-saratoga-tfrc/ There are several interesting things about Saratoga related to transport protocol evolution, so I thought it might be another interesting datapoint in the field. Off the top of my head, relevant features are: - runs over UDP for deployability - can run over highly asymmetric paths (e.g. 1000s-to-1 b/w ratio) - flexibly implements different congestion control algorithms - copes with extremely high latency or unidirectional connectivity > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > in contributing actively to the session. If it's of interest, I could briefly present the state of Saratoga (e.g. 5 minutes), and possible future plans. -- Wes Eddy MTI Systems From linda.dunbar@huawei.com Thu Oct 24 11:19:42 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7169D11E81CF for ; Thu, 24 Oct 2013 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dSXJAl49xMs for ; Thu, 24 Oct 2013 11:19:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2928F11E8357 for ; Thu, 24 Oct 2013 11:19:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXD92384; Thu, 24 Oct 2013 18:19:32 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 19:19:27 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 19:19:31 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 11:19:26 -0700 From: Linda Dunbar To: Martin Stiemerling , "tsv-area@ietf.org" Subject: RE: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Thread-Topic: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Thread-Index: AQHOz79UkEpv0gN/xk+Sv79Q9+F4hpoEAzrA Date: Thu, 24 Oct 2013 18:19:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> References: <526776F0.50401@gmail.com> In-Reply-To: <526776F0.50401@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.134.225] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:19:43 -0000 Martin and Spencer,=20 Possible to include HTTP? More and more applications run HTTP, and many peo= ple believe that HTTP is the future of the transport protocol(s).=20 Linda > -----Original Message----- > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > Behalf Of Martin Stiemerling > Sent: Wednesday, October 23, 2013 2:13 AM > To: tsv-area@ietf.org > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport > Protocols" @ IETF-88 >=20 > Dear all, >=20 > We would like to give time to the Transport Area to discuss any > potential need to evolve the IETF transport protocols. >=20 > There are a number of proposals discussed in the IETF and outside of > the > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > QUIC [3]), and also discussions about the congestion control approach > to > be used (e.g., delay-based [4], LEDBAT [5]). >=20 > (We are fully aware that this list of proposals is incomplete) >=20 > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > Vancouver to discuss this topic. >=20 > More information to come soon. >=20 > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > in contributing actively to the session. >=20 > Thanks, >=20 > Spencer and Martin, your TSV ADs. >=20 > References > [1] https://developers.google.com/speed/protocols/tcp-laminar > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > [3] > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- > ev2jRFUoVD34/edit?pli=3D1 > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > [5] https://datatracker.ietf.org/wg/ledbat/charter/ From scott.brim@gmail.com Thu Oct 24 12:21:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5B011E83AC for ; Thu, 24 Oct 2013 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+hHuvGsQU9y for ; Thu, 24 Oct 2013 12:21:05 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2711E839A for ; Thu, 24 Oct 2013 12:21:05 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id g12so2900719oah.33 for ; Thu, 24 Oct 2013 12:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tsUu1aCttXm3YhZd/GnF83tSnqfjbyvaSEhDURjis+k=; b=KLb24sASAcZ9kQtq0cbKIzPrLNx7Cz2yzQ5RCh357CK5bGw0QU4tpSAYfPsQJBZT+u vdIreqmxMzBj815MnzmB/pIRTzuBgB5MogGYlbccQKz9tcSxYgZ+ZSqniluEY8ThXfCw 24ZwsKxxRL0olMbLJgxXVaPNhp7m0OfddFrX/ygqMdG0hbGf6d9ub6RD01Hw1OeYU7R4 KSWWDpo+3VMJe+aS6enNankSEzkrmQ7cE4MpmNnBFReelK6B4hdTZoirTYP72iyoGH7V 17FMrcCpjJ/c9ofXN/RCbyp5LzmEU1QQ2h+lL+pKgK7m6yVX/HGonBPrB6SpkeWgzXmC ZddQ== X-Received: by 10.60.99.37 with SMTP id en5mr1639411oeb.78.1382642464638; Thu, 24 Oct 2013 12:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Thu, 24 Oct 2013 12:20:44 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> From: Scott Brim Date: Thu, 24 Oct 2013 15:20:44 -0400 Message-ID: Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 To: Linda Dunbar Content-Type: multipart/alternative; boundary=047d7b33d7e4f4d11304e9818842 Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:21:05 -0000 --047d7b33d7e4f4d11304e9818842 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 24, 2013 at 2:19 PM, Linda Dunbar wrote: > Martin and Spencer, > > Possible to include HTTP? More and more applications run HTTP, and many > people believe that HTTP is the future of the transport protocol(s). QUIC is already mentioned. --047d7b33d7e4f4d11304e9818842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 24, 2013 at 2:19 PM, Linda Dunbar <lind= a.dunbar@huawei.com> wrote:

Martin and Spencer,

Possible to include HTTP? More and more applications run HTTP, and many peo= ple believe that HTTP is the future of the transport protocol(s).

QUIC is already mentioned.=A0
--047d7b33d7e4f4d11304e9818842-- From eckert@cisco.com Thu Oct 24 12:32:06 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0472111E839E for ; Thu, 24 Oct 2013 12:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.304 X-Spam-Level: X-Spam-Status: No, score=-10.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ch56Y8DSswt for ; Thu, 24 Oct 2013 12:31:57 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3011E8379 for ; Thu, 24 Oct 2013 12:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4453; q=dns/txt; s=iport; t=1382643116; x=1383852716; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tSD/0XtEeXnIA07uas97WzwCH+MEVfRiKMKNZvEoD3w=; b=AUKlTvs9xlFfWL4ZINnSUARv1gGtDdM8mKJ8hDvsFZ8yIv+iRCDfkZpC whEgC3gPsIZyx5a8a9nkRqKmypck6TEMnARhf7C4ZRRyS0QXn5+x1qtBH Cb5B9IYgvvQ3Jca9tuDWO+pexmbYqQMQMsQrU3Vfs6CoTIywUMUXoOya8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEB1aVKrRDoH/2dsb2JhbABZgwc4vzKBHhZ0giUBAQEEJxMrFAwECxEBAwEBAQkeBw8FMgMGDhOIBg66Io9NBwaEJgOJP45KAYEvkFiBZoFeHA X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="95518885" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 24 Oct 2013 19:31:54 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9OJVrS0002412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 19:31:53 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9OJVqYN026049; Thu, 24 Oct 2013 12:31:52 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9OJVqtD026048; Thu, 24 Oct 2013 12:31:52 -0700 Date: Thu, 24 Oct 2013 12:31:52 -0700 From: Toerless Eckert To: Linda Dunbar Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Message-ID: <20131024193152.GQ11229@cisco.com> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> User-Agent: Mutt/1.4.2.2i Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:32:06 -0000 Reminds me a bit of the situation early on in RMT. There where so many proposal for the "one protocol will save the world" that the WG had to step back and first create a taxonomy of building block to sort through the necessary/beneficial functions in them and only after that was done try to compose full-protocol recommendations. Aka: would be lovely if this effort could lead to some useful taxonomy of network conditions and components driving the innovations. I am a bit cynical here, because if i look at the overall scope of stuff going on (not specifically the ones proposed to be talked about), what i see is this (yes, some pessimistic blinders used): 60% workaround to get through NAT/FW with a transport flow 10% workaround to get QoS without having QoS in the network 10% workarounds to use multiple interfaces without having mobile IP 10% workarounds to make new congestion control compete with the dumbest TCP stack and stupiest queue. 9% workarounds to do transport stuff inside the app as opposed to traditionally the OS because OS stacks are also considered inagile. 1% all the other cool stuff SCTP had already try to aggregate but re-done in the context of the above workarounds. So, the evolution of transport protocols i see is this architecture: -> the network is a bunch of bad packet forwarders with a lot of NAT/FW, no DiffServ or other QoS, not even good AQM, no mobility, but a lot of congestion by badly behaving transport stacks. -> The OS likewise is not agile enough to deploy innovation. -> In-Middleware/App- Transport stacks to the rescue with all the above inside the transport stack, designed only against the lowest common denominator. I totally get the business need that tranport stacks must do these workarounds, even if it's just for the bottom 20% paths/subscribers of interest. But what we have is overwhelmingly a focus on ONLY this bottom 20%, and little in the transport stacks that balances expectations. If you bring in MUSTs for workarounds at the bottom, i think the same spec MUST also include the appropriate improvements for the top. Otherwise the market dynamics will just continue to cause a race to the bottom and the title of the slot should be: "Evolution of transport stacks - Rewarding bad networks and OS" Cheers toerless On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote: > Martin and Spencer, > > Possible to include HTTP? More and more applications run HTTP, and many people believe that HTTP is the future of the transport protocol(s). > > Linda > > > -----Original Message----- > > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > > Behalf Of Martin Stiemerling > > Sent: Wednesday, October 23, 2013 2:13 AM > > To: tsv-area@ietf.org > > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport > > Protocols" @ IETF-88 > > > > Dear all, > > > > We would like to give time to the Transport Area to discuss any > > potential need to evolve the IETF transport protocols. > > > > There are a number of proposals discussed in the IETF and outside of > > the > > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > > QUIC [3]), and also discussions about the congestion control approach > > to > > be used (e.g., delay-based [4], LEDBAT [5]). > > > > (We are fully aware that this list of proposals is incomplete) > > > > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > > Vancouver to discuss this topic. > > > > More information to come soon. > > > > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > > in contributing actively to the session. > > > > Thanks, > > > > Spencer and Martin, your TSV ADs. > > > > References > > [1] https://developers.google.com/speed/protocols/tcp-laminar > > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > > [3] > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- > > ev2jRFUoVD34/edit?pli=1 > > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > > [5] https://datatracker.ietf.org/wg/ledbat/charter/ -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From mattmathis@google.com Thu Oct 24 13:11:31 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7F11E82F8 for ; Thu, 24 Oct 2013 13:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44eqwDGIcmMb for ; Thu, 24 Oct 2013 13:11:30 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD7211E825C for ; Thu, 24 Oct 2013 13:11:30 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so4921653iec.13 for ; Thu, 24 Oct 2013 13:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TnMjfWpGMlifFQVbPjFgm0G73Gc+BWNABIhRxk+y+Tc=; b=pifiFYRKIs0B4SgwddG021ByINerS0r/LxXR8fc18zeHn3p7O7+C6nvA8lKBDazo3A nvjdds1yoXynwPfDDyWYOVEc7xp3iccpyrTkRz4VKCjSDShHhkq1btxW02i3MAnExG/V NMIE/JuzYkguGvwpldwdlagq3ZCCp7TBPEmT8CX/a7+nBtqL4wGTiYDKhRpH0jszflHR RhTmNpVhZOpO0VFefeA9zfz+NVSuHE09rq1I/Y6/g0j0gzYKiIa/TWNLpMlMgxMSZF5U p6Gfz/9SAVrh1VfP1bU2k4B+26iJbep1OLsRQGC0FnnGoPoCFi4owxEZJANDGXFAeX5Z Zw2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TnMjfWpGMlifFQVbPjFgm0G73Gc+BWNABIhRxk+y+Tc=; b=HZYzSoBkVWuRPtT/5EFb44Ae1hExRmDRikBEdQykREZ9CXl6FMIcZBxFMHUeIMf/WB 8T/LyaWa6gqG9psGVbuMKlqj9FrlerxYuKIB3Q9hs0o/9kXwhLXWgZn/+XHmNNeOEikY M+ksH9g0B8k0JETeiOL4CayB0Pgql1L3AXIs4Cq32NoTYR6mH4loTWEztdG6ZU9sgpwD U4gV0Ja13j1uddk9skT9v8fj8jWrRDnnBI5W95DLXtiMgcOk6yMhxb829s+cuV6Pl+SP VClxYrXDwE6TEmZvf3/kWqIGdT0q2eWIXGz1EAdP9M2peDK2abd/NcySQa3tfTLII+8S VQ4A== X-Gm-Message-State: ALoCoQnbjIbJ4dMekLemOHbPvWAINnD0K2AVpDlx+FtJ3Roj6+Am355THqK+0o1zga9C3OEbVfb7c629euXJ158hZXFUQezTl/RImWxUirjkI2b6vg97PrjHljFpJ0KxwLyuQk+da3QUDj+unzG7H7rOlZLokFQTu6xTEy5y9NFpFZ+VBmCwtjf72hGW6pgFcFyVZZDwryMy MIME-Version: 1.0 X-Received: by 10.42.30.143 with SMTP id v15mr2812307icc.24.1382645489717; Thu, 24 Oct 2013 13:11:29 -0700 (PDT) Received: by 10.64.243.66 with HTTP; Thu, 24 Oct 2013 13:11:29 -0700 (PDT) In-Reply-To: <20131024193152.GQ11229@cisco.com> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <20131024193152.GQ11229@cisco.com> Date: Thu, 24 Oct 2013 13:11:29 -0700 Message-ID: Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 From: Matt Mathis To: Toerless Eckert Content-Type: multipart/alternative; boundary=20cf301d3e7a43f3e304e9823d1f Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:11:31 -0000 --20cf301d3e7a43f3e304e9823d1f Content-Type: text/plain; charset=ISO-8859-1 Ok, so here is a slightly less cynical question: suppose you could map the cruft at scale. What would you do with that information? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Thu, Oct 24, 2013 at 12:31 PM, Toerless Eckert wrote: > Reminds me a bit of the situation early on in RMT. There where > so many proposal for the "one protocol will save the world" that the WG > had to step back and first create a taxonomy of building block to > sort through the necessary/beneficial functions in them and only after > that was done try to compose full-protocol recommendations. > > Aka: would be lovely if this effort could lead to some useful taxonomy > of network conditions and components driving the innovations. > > I am a bit cynical here, because if i look at the overall scope of > stuff going on (not specifically the ones proposed to be talked about), > what i see is this (yes, some pessimistic blinders used): > > 60% workaround to get through NAT/FW with a transport flow > 10% workaround to get QoS without having QoS in the network > 10% workarounds to use multiple interfaces without having mobile IP > 10% workarounds to make new congestion control compete with the > dumbest TCP stack and stupiest queue. > 9% workarounds to do transport stuff inside the app as opposed to > traditionally the OS because OS stacks are also considered inagile. > 1% all the other cool stuff SCTP had already try to aggregate but > re-done in the context of the above workarounds. > > So, the evolution of transport protocols i see is this architecture: > > -> the network is a bunch of bad packet forwarders with a lot of NAT/FW, > no DiffServ or other QoS, not even good AQM, no mobility, but a lot > of congestion by badly behaving transport stacks. > -> The OS likewise is not agile enough to deploy innovation. > -> In-Middleware/App- Transport stacks to the rescue with all the above > inside the transport stack, designed only against the lowest common > denominator. > > I totally get the business need that tranport stacks must do these > workarounds, > even if it's just for the bottom 20% paths/subscribers of interest. But > what we have is overwhelmingly a focus on ONLY this bottom 20%, and little > in the transport stacks that balances expectations. If you bring in MUSTs > for workarounds at the bottom, i think the same spec MUST also include the > appropriate improvements for the top. Otherwise the market dynamics will > just continue to cause a race to the bottom and the title of the slot > should > be: > > "Evolution of transport stacks - Rewarding bad networks and OS" > > Cheers > toerless > > > On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote: > > Martin and Spencer, > > > > Possible to include HTTP? More and more applications run HTTP, and many > people believe that HTTP is the future of the transport protocol(s). > > > > Linda > > > > > -----Original Message----- > > > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > > > Behalf Of Martin Stiemerling > > > Sent: Wednesday, October 23, 2013 2:13 AM > > > To: tsv-area@ietf.org > > > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport > > > Protocols" @ IETF-88 > > > > > > Dear all, > > > > > > We would like to give time to the Transport Area to discuss any > > > potential need to evolve the IETF transport protocols. > > > > > > There are a number of proposals discussed in the IETF and outside of > > > the > > > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > > > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > > > QUIC [3]), and also discussions about the congestion control approach > > > to > > > be used (e.g., delay-based [4], LEDBAT [5]). > > > > > > (We are fully aware that this list of proposals is incomplete) > > > > > > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > > > Vancouver to discuss this topic. > > > > > > More information to come soon. > > > > > > Let Spencer and me know at tsv-ads@tools.ietf.org if you are > interested > > > in contributing actively to the session. > > > > > > Thanks, > > > > > > Spencer and Martin, your TSV ADs. > > > > > > References > > > [1] https://developers.google.com/speed/protocols/tcp-laminar > > > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > > > [3] > > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- > > > ev2jRFUoVD34/edit?pli=1 > > > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > > > [5] https://datatracker.ietf.org/wg/ledbat/charter/ > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > > --20cf301d3e7a43f3e304e9823d1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, so here is a slightly less cynical question: suppose y= ou could map the cruft at scale. What would you do with that information?

Thanks,
--MM--
The best way to predict the future is to create it. =A0- Alan Kay=

Privacy matters! =A0We know from recent events that people are usin= g our services to speak in defiance of unjust governments. =A0 We treat pri= vacy and security as matters of life and death, because for some users, the= y are.

On Thu, Oct 24, 2013 at 12:31 PM, Toerle= ss Eckert <eckert@cisco.com> wrote:
Reminds me a bit of the situation early on in RMT. There where
so many proposal for the "one protocol will save the world" that = the WG
had to step back and first create a taxonomy of building block to
sort through the necessary/beneficial functions in them and only after
that was done try to compose full-protocol recommendations.

Aka: would be lovely if this effort could lead to some useful taxonomy
of network conditions and components driving the innovations.

I am a bit cynical here, because if i look at the overall scope of
stuff going on (not specifically the ones proposed to be talked about),
what i see is this (yes, some pessimistic blinders used):

=A0 =A060% workaround to get through NAT/FW with a transport flow
=A0 =A010% workaround to get QoS without having QoS in the network
=A0 =A010% workarounds to use multiple interfaces without having mobile IP<= br> =A0 =A010% workarounds to make new congestion control compete with the
=A0 =A0 =A0 =A0dumbest TCP stack and stupiest queue.
=A0 =A0 9% workarounds to do transport stuff inside the app as opposed to =A0 =A0 =A0 =A0traditionally the OS because OS stacks are also considered i= nagile.
=A0 =A0 1% all the other cool stuff SCTP had already try to aggregate but =A0 =A0 =A0 =A0re-done in the context of the above workarounds.

So, the evolution of transport protocols i see is this architecture:

=A0-> the network is a bunch of bad packet forwarders with a lot of NAT/= FW,
=A0 =A0 no DiffServ or other QoS, not even good AQM, no mobility, but a lot=
=A0 =A0 of congestion by badly behaving transport stacks.
=A0-> The OS likewise is not agile enough to deploy innovation.
=A0-> In-Middleware/App- Transport stacks to the rescue with all the abo= ve
=A0 =A0 inside the transport stack, designed only against the lowest common=
=A0 =A0 denominator.

I totally get the business need that tranport stacks must do these workarou= nds,
even if it's just for the bottom 20% paths/subscribers of interest. But=
what we have is overwhelmingly a focus on ONLY this bottom 20%, and little<= br> in the transport stacks that balances expectations. If you bring in MUSTs for workarounds at the bottom, i think the same spec MUST also include the<= br> appropriate improvements for the top. Otherwise the market dynamics will just continue to cause a race to the bottom and the title of the slot shoul= d
be:

=A0"Evolution of transport stacks - Rewarding bad networks and OS"= ;

Cheers
=A0 =A0 toerless

On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote:
> Martin and Spencer,
>
> Possible to include HTTP? More and more applications run HTTP, and man= y people believe that HTTP is the future of the transport protocol(s).
>
> Linda
>
> > -----Original Message-----
> > From: tsv-area-bounc= es@ietf.org [mailto:tsv-ar= ea-bounces@ietf.org] On
> > Behalf Of Martin Stiemerling
> > Sent: Wednesday, October 23, 2013 2:13 AM
> > To: tsv-area@ietf.org > > Subject: Announcing the TSVAREA session on "Evolution of IET= F Transport
> > Protocols" @ IETF-88
> >
> > Dear all,
> >
> > We would like to give time to the Transport Area to discuss any > > potential need to evolve the IETF transport protocols.
> >
> > There are a number of proposals discussed in the IETF and outside= of
> > the
> > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing par= ts of
> > TCP (e.g., TCP Minion [2]), completely new transport protocols (e= .g.
> > QUIC [3]), and also discussions about the congestion control appr= oach
> > to
> > be used (e.g., delay-based [4], LEDBAT [5]).
> >
> > (We are fully aware that this list of proposals is incomplete) > >
> > Spencer and I are planning a slot in the TSVAREA session at IETF = 88 in
> > Vancouver to discuss this topic.
> >
> > More information to come soon.
> >
> > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested
> > in contributing actively to the session.
> >
> > Thanks,
> >
> > =A0 =A0Spencer and Martin, your TSV ADs.
> >
> > References
> > [1] https://developers.google.com/speed/protocols/tc= p-laminar
> > [2] http://tools.ietf.org/html/draft-iyengar-minion-co= ncept
> > [3]
> > https://docs.google.com/document/d/1RNHkx_= VvKWyWg6Lr8SZ-saqsQx7rFV-
> > ev2jRFUoVD34/edit?pli=3D1
> > [4] https://datatracker.ietf.org/wg/rmcat/charter/
> > [5] https://datatracker.ietf.org/wg/ledbat/charter/

--
---
Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

--20cf301d3e7a43f3e304e9823d1f-- From michawe@ifi.uio.no Thu Oct 24 14:33:48 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEED911E823B for ; Thu, 24 Oct 2013 14:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxeZvQv0V+aa for ; Thu, 24 Oct 2013 14:33:44 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 037C511E81DF for ; Thu, 24 Oct 2013 14:33:44 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VZSXB-0006NO-GT; Thu, 24 Oct 2013 23:33:37 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VZSXA-0006VN-PA; Thu, 24 Oct 2013 23:33:37 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 From: Michael Welzl In-Reply-To: <20131024193152.GQ11229@cisco.com> Date: Thu, 24 Oct 2013 23:33:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CD05D2A-2CA2-44B6-9F75-B93A58D03258@ifi.uio.no> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <20131024193152.GQ11229@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 16 sum msgs/h 6 total rcpts 8954 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E5DF214663A563C02C85D57FDC4BFD93F2CBC636 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 390 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 21:33:48 -0000 Hi, I should have cc'ed the group - I have asked Martin and Spencer to be = able to contribute to this session, related to this effort: https://sites.google.com/site/transportprotocolservices/ I think this is in line with your wish for a "step back" to create a = taxonomy. It's not exactly that, and not focused on the network, but I = think it's one necessary step if we want to make some real progress for = the transport layer here. Now, getting to what you want, as per what you write below, if you had = an API that would be a little more abstract than saying "give me TCP = please", then an OS or, heck, user-space "transport system" could just = as well provide e.g. QoS *when it's there* underneath this API. Or it = could use a protocol that doesn't require a lot of work-arounds in = situations where they are not needed. IMO the key is in getting the "best effort" notion represented in the = API between the application and transport. It's not there now, and = that's at least one reason why QoS for the broad Internet could never be = brought to the application level, which is a problem that was already = noticed in RFC2990. Let applications say what they want, and let them live with the fact = that in the worst case, they'll only get a normal TCP connection across = the best-effort Internet, I say. I'll talk about that at the IAB ITAT = workshop in December, see = http://heim.ifi.uio.no/michawe//research/publications/iab-itat-workshop201= 3.pdf ... but incorporating stuff like that is a broader vision than the one = in the Transport Services effort (which explicitly excludes QoS), and I = don't think it would be wise to incorporate it there. Cheers, Michael On 24. okt. 2013, at 21:31, Toerless Eckert wrote: > Reminds me a bit of the situation early on in RMT. There where > so many proposal for the "one protocol will save the world" that the = WG > had to step back and first create a taxonomy of building block to > sort through the necessary/beneficial functions in them and only after > that was done try to compose full-protocol recommendations. >=20 > Aka: would be lovely if this effort could lead to some useful taxonomy > of network conditions and components driving the innovations. >=20 > I am a bit cynical here, because if i look at the overall scope of > stuff going on (not specifically the ones proposed to be talked = about), > what i see is this (yes, some pessimistic blinders used): >=20 > 60% workaround to get through NAT/FW with a transport flow > 10% workaround to get QoS without having QoS in the network > 10% workarounds to use multiple interfaces without having mobile IP > 10% workarounds to make new congestion control compete with the > dumbest TCP stack and stupiest queue. > 9% workarounds to do transport stuff inside the app as opposed to > traditionally the OS because OS stacks are also considered = inagile. > 1% all the other cool stuff SCTP had already try to aggregate but > re-done in the context of the above workarounds. >=20 > So, the evolution of transport protocols i see is this architecture: >=20 > -> the network is a bunch of bad packet forwarders with a lot of = NAT/FW, > no DiffServ or other QoS, not even good AQM, no mobility, but a lot > of congestion by badly behaving transport stacks. > -> The OS likewise is not agile enough to deploy innovation. > -> In-Middleware/App- Transport stacks to the rescue with all the = above > inside the transport stack, designed only against the lowest common > denominator. >=20 > I totally get the business need that tranport stacks must do these = workarounds, > even if it's just for the bottom 20% paths/subscribers of interest. = But > what we have is overwhelmingly a focus on ONLY this bottom 20%, and = little > in the transport stacks that balances expectations. If you bring in = MUSTs > for workarounds at the bottom, i think the same spec MUST also include = the > appropriate improvements for the top. Otherwise the market dynamics = will > just continue to cause a race to the bottom and the title of the slot = should > be: >=20 > "Evolution of transport stacks - Rewarding bad networks and OS" >=20 > Cheers > toerless >=20 >=20 > On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote: >> Martin and Spencer,=20 >>=20 >> Possible to include HTTP? More and more applications run HTTP, and = many people believe that HTTP is the future of the transport = protocol(s).=20 >>=20 >> Linda >>=20 >>> -----Original Message----- >>> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] = On >>> Behalf Of Martin Stiemerling >>> Sent: Wednesday, October 23, 2013 2:13 AM >>> To: tsv-area@ietf.org >>> Subject: Announcing the TSVAREA session on "Evolution of IETF = Transport >>> Protocols" @ IETF-88 >>>=20 >>> Dear all, >>>=20 >>> We would like to give time to the Transport Area to discuss any >>> potential need to evolve the IETF transport protocols. >>>=20 >>> There are a number of proposals discussed in the IETF and outside of >>> the >>> IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts = of >>> TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. >>> QUIC [3]), and also discussions about the congestion control = approach >>> to >>> be used (e.g., delay-based [4], LEDBAT [5]). >>>=20 >>> (We are fully aware that this list of proposals is incomplete) >>>=20 >>> Spencer and I are planning a slot in the TSVAREA session at IETF 88 = in >>> Vancouver to discuss this topic. >>>=20 >>> More information to come soon. >>>=20 >>> Let Spencer and me know at tsv-ads@tools.ietf.org if you are = interested >>> in contributing actively to the session. >>>=20 >>> Thanks, >>>=20 >>> Spencer and Martin, your TSV ADs. >>>=20 >>> References >>> [1] https://developers.google.com/speed/protocols/tcp-laminar >>> [2] http://tools.ietf.org/html/draft-iyengar-minion-concept >>> [3] >>> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- >>> ev2jRFUoVD34/edit?pli=3D1 >>> [4] https://datatracker.ietf.org/wg/rmcat/charter/ >>> [5] https://datatracker.ietf.org/wg/ledbat/charter/ >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From bob.briscoe@bt.com Fri Oct 25 07:19:36 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4347211E83E6 for ; Fri, 25 Oct 2013 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbIWq64FkpEz for ; Fri, 25 Oct 2013 07:19:31 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 916CE11E81BB for ; Fri, 25 Oct 2013 07:19:30 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 25 Oct 2013 15:19:25 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 25 Oct 2013 15:19:28 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Fri, 25 Oct 2013 15:19:25 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9PEJOUq006394; Fri, 25 Oct 2013 15:19:24 +0100 Message-ID: <201310251419.r9PEJOUq006394@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Oct 2013 15:19:18 +0100 To: Toerless Eckert From: Bob Briscoe Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 In-Reply-To: <20131024193152.GQ11229@cisco.com> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <20131024193152.GQ11229@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:19:36 -0000 Toerless, * QoS in the network is not unequivocally a good thing - for instance, if you can make delay predictably low for all BE traffic, you don't need or want the complexity of differentiated latency. * Similarly, Mobile IP is not unequivocally a good thing. Rest assured my slot will not be about the bottom 20%, it is about enabling a "top 20%" combination of AQM and transport (DCTCP) to be deployable alongside the bottom 20%, rather than stuck out of reach in data centres. But, in general, I agree your point is true for many of these TSV efforts - and in a maturing network like the Internet you would expect that. However, universal damnation of everything wasn't warranted. Bob At 20:31 24/10/2013, Toerless Eckert wrote: >Reminds me a bit of the situation early on in RMT. There where >so many proposal for the "one protocol will save the world" that the WG >had to step back and first create a taxonomy of building block to >sort through the necessary/beneficial functions in them and only after >that was done try to compose full-protocol recommendations. > >Aka: would be lovely if this effort could lead to some useful taxonomy >of network conditions and components driving the innovations. > >I am a bit cynical here, because if i look at the overall scope of >stuff going on (not specifically the ones proposed to be talked about), >what i see is this (yes, some pessimistic blinders used): > > 60% workaround to get through NAT/FW with a transport flow > 10% workaround to get QoS without having QoS in the network > 10% workarounds to use multiple interfaces without having mobile IP > 10% workarounds to make new congestion control compete with the > dumbest TCP stack and stupiest queue. > 9% workarounds to do transport stuff inside the app as opposed to > traditionally the OS because OS stacks are also considered inagile. > 1% all the other cool stuff SCTP had already try to aggregate but > re-done in the context of the above workarounds. > >So, the evolution of transport protocols i see is this architecture: > > -> the network is a bunch of bad packet forwarders with a lot of NAT/FW, > no DiffServ or other QoS, not even good AQM, no mobility, but a lot > of congestion by badly behaving transport stacks. > -> The OS likewise is not agile enough to deploy innovation. > -> In-Middleware/App- Transport stacks to the rescue with all the above > inside the transport stack, designed only against the lowest common > denominator. > >I totally get the business need that tranport stacks must do these >workarounds, >even if it's just for the bottom 20% paths/subscribers of interest. But >what we have is overwhelmingly a focus on ONLY this bottom 20%, and little >in the transport stacks that balances expectations. If you bring in MUSTs >for workarounds at the bottom, i think the same spec MUST also include the >appropriate improvements for the top. Otherwise the market dynamics will >just continue to cause a race to the bottom and the title of the slot should >be: > > "Evolution of transport stacks - Rewarding bad networks and OS" > >Cheers > toerless > > >On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote: > > Martin and Spencer, > > > > Possible to include HTTP? More and more applications run HTTP, > and many people believe that HTTP is the future of the transport protocol(s). > > > > Linda > > > > > -----Original Message----- > > > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > > > Behalf Of Martin Stiemerling > > > Sent: Wednesday, October 23, 2013 2:13 AM > > > To: tsv-area@ietf.org > > > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport > > > Protocols" @ IETF-88 > > > > > > Dear all, > > > > > > We would like to give time to the Transport Area to discuss any > > > potential need to evolve the IETF transport protocols. > > > > > > There are a number of proposals discussed in the IETF and outside of > > > the > > > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > > > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > > > QUIC [3]), and also discussions about the congestion control approach > > > to > > > be used (e.g., delay-based [4], LEDBAT [5]). > > > > > > (We are fully aware that this list of proposals is incomplete) > > > > > > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > > > Vancouver to discuss this topic. > > > > > > More information to come soon. > > > > > > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > > > in contributing actively to the session. > > > > > > Thanks, > > > > > > Spencer and Martin, your TSV ADs. > > > > > > References > > > [1] https://developers.google.com/speed/protocols/tcp-laminar > > > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > > > [3] > > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- > > > ev2jRFUoVD34/edit?pli=1 > > > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > > > [5] https://datatracker.ietf.org/wg/ledbat/charter/ > >-- >--- >Toerless Eckert, eckert@cisco.com >Cisco NSSTG Systems & Technology Architecture >SDN: Let me play with the network, mommy! ________________________________________________________________ Bob Briscoe, BT From eckert@cisco.com Fri Oct 25 09:50:03 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE01611E8373 for ; Fri, 25 Oct 2013 09:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.323 X-Spam-Level: X-Spam-Status: No, score=-10.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7Z3hlsqbWyF for ; Fri, 25 Oct 2013 09:49:59 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 32F0921F9CAD for ; Fri, 25 Oct 2013 09:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7882; q=dns/txt; s=iport; t=1382719799; x=1383929399; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=r1jjYkwBwYuiw36idrws/DDReeNrfWRsM+zpCXO349U=; b=KAMOum2Yu90l3nyO5YAwqD1Wbsjbyab1Mi5arSajSOCjed+gzXUuT2Cm zUI9KwP2Cg/50r9c2JQ2KnZBZ+GB5u7H/XpuB08jU4k8YWPXi+rWrQy24 7YeRMpf7AS/kDcNyrB1qwoqX/Hq9H9R5ec6YtV3OX2NeIxBzZLd9K1nok Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAF+galKrRDoI/2dsb2JhbABZgwc4vx2BIhZ0giUBAQEEJxMrDwUMBAsRAQMBAQEJHgcPBTIDBg4TG4drDrlQj1MHBoQmA4k/jkoBgS+QWIFogV4c X-IronPort-AV: E=Sophos;i="4.93,571,1378857600"; d="scan'208";a="93015162" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 25 Oct 2013 16:49:56 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9PGnt1J005726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 16:49:55 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r9PGntcB003361; Fri, 25 Oct 2013 09:49:55 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r9PGnt1G003360; Fri, 25 Oct 2013 09:49:55 -0700 Date: Fri, 25 Oct 2013 09:49:55 -0700 From: Toerless Eckert To: Bob Briscoe Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Message-ID: <20131025164955.GW11229@cisco.com> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <20131024193152.GQ11229@cisco.com> <201310251419.r9PEJOUq006394@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201310251419.r9PEJOUq006394@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.2.2i Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:50:03 -0000 Very much in agreement with what you say. Just wanted to help upleveling the discussion from just the building blocks over to an analysis how the work we invest will help to raise the level of service also at L3/L2 (if/when appropriate/beneficial) and eliminate cruft there instead of treating it like a protected species that is taking cycles away from better solutions. I think there is just a very logical barrier between infrastructure equipment mostly doing <=L3 and hosts primarily >=L4 and integration across that barier is naturally focussed on working around what the other side does badly instead of really pushing through good requirements against the other side. And the higher layers, closer to te apps are just naturally in the stronger position to make their desires happen, so it is most important that they position themselves to raise the right requirements to the lower layers. To not make it too long, let me just chime into your QoS point: No strategic argument about latency. Just that its going to be IMHO a decade effort. A lot of CC unaware traffic will first go through a circuit breaker stage and that traffic will still kill low latency. But i primarily worry about bandwidth share. - With just the likely CC/AQM work happening, we will just end up with "all flows can use no more than 3..5 times the bandwidth of other flows". - If that's not good enough, go figure out how to use DiffServ. DiffServ sucks. Managing WFQ parameters is primarily an OSS job creation program. We have no IETF solution/strategy to _easily_ build and enforce policies to differentiate BW allocation across traffic buckets/flows. Of course, this bitching here is self-serving, because IMHO the top problem when going beyond "equal within 3..5 times BW" is to have a framework to know more about the purpose and expectations of the traffic buckets/flows at L3/L4 - see our framework doc ;-). Once we have this knowledge, we can start reasonably working out better mechanisms for more appropriate policies. Cheers Toerless On Fri, Oct 25, 2013 at 03:19:18PM +0100, Bob Briscoe wrote: > Toerless, > > * QoS in the network is not unequivocally a good thing - for > instance, if you can make delay predictably low for all BE traffic, > you don't need or want the complexity of differentiated latency. > * Similarly, Mobile IP is not unequivocally a good thing. > > Rest assured my slot will not be about the bottom 20%, it is about > enabling a "top 20%" combination of AQM and transport (DCTCP) to be > deployable alongside the bottom 20%, rather than stuck out of reach > in data centres. > > But, in general, I agree your point is true for many of these TSV > efforts - and in a maturing network like the Internet you would > expect that. However, universal damnation of everything wasn't warranted. > > > Bob > > At 20:31 24/10/2013, Toerless Eckert wrote: > >Reminds me a bit of the situation early on in RMT. There where > >so many proposal for the "one protocol will save the world" that the WG > >had to step back and first create a taxonomy of building block to > >sort through the necessary/beneficial functions in them and only after > >that was done try to compose full-protocol recommendations. > > > >Aka: would be lovely if this effort could lead to some useful taxonomy > >of network conditions and components driving the innovations. > > > >I am a bit cynical here, because if i look at the overall scope of > >stuff going on (not specifically the ones proposed to be talked about), > >what i see is this (yes, some pessimistic blinders used): > > > > 60% workaround to get through NAT/FW with a transport flow > > 10% workaround to get QoS without having QoS in the network > > 10% workarounds to use multiple interfaces without having mobile IP > > 10% workarounds to make new congestion control compete with the > > dumbest TCP stack and stupiest queue. > > 9% workarounds to do transport stuff inside the app as opposed to > > traditionally the OS because OS stacks are also considered inagile. > > 1% all the other cool stuff SCTP had already try to aggregate but > > re-done in the context of the above workarounds. > > > >So, the evolution of transport protocols i see is this architecture: > > > > -> the network is a bunch of bad packet forwarders with a lot of NAT/FW, > > no DiffServ or other QoS, not even good AQM, no mobility, but a lot > > of congestion by badly behaving transport stacks. > > -> The OS likewise is not agile enough to deploy innovation. > > -> In-Middleware/App- Transport stacks to the rescue with all the above > > inside the transport stack, designed only against the lowest common > > denominator. > > > >I totally get the business need that tranport stacks must do these > >workarounds, > >even if it's just for the bottom 20% paths/subscribers of interest. But > >what we have is overwhelmingly a focus on ONLY this bottom 20%, and little > >in the transport stacks that balances expectations. If you bring in MUSTs > >for workarounds at the bottom, i think the same spec MUST also include the > >appropriate improvements for the top. Otherwise the market dynamics will > >just continue to cause a race to the bottom and the title of the slot > >should > >be: > > > > "Evolution of transport stacks - Rewarding bad networks and OS" > > > >Cheers > > toerless > > > > > >On Thu, Oct 24, 2013 at 06:19:25PM +0000, Linda Dunbar wrote: > >> Martin and Spencer, > >> > >> Possible to include HTTP? More and more applications run HTTP, > >and many people believe that HTTP is the future of the transport > >protocol(s). > >> > >> Linda > >> > >> > -----Original Message----- > >> > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > >> > Behalf Of Martin Stiemerling > >> > Sent: Wednesday, October 23, 2013 2:13 AM > >> > To: tsv-area@ietf.org > >> > Subject: Announcing the TSVAREA session on "Evolution of IETF Transport > >> > Protocols" @ IETF-88 > >> > > >> > Dear all, > >> > > >> > We would like to give time to the Transport Area to discuss any > >> > potential need to evolve the IETF transport protocols. > >> > > >> > There are a number of proposals discussed in the IETF and outside of > >> > the > >> > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > >> > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > >> > QUIC [3]), and also discussions about the congestion control approach > >> > to > >> > be used (e.g., delay-based [4], LEDBAT [5]). > >> > > >> > (We are fully aware that this list of proposals is incomplete) > >> > > >> > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > >> > Vancouver to discuss this topic. > >> > > >> > More information to come soon. > >> > > >> > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > >> > in contributing actively to the session. > >> > > >> > Thanks, > >> > > >> > Spencer and Martin, your TSV ADs. > >> > > >> > References > >> > [1] https://developers.google.com/speed/protocols/tcp-laminar > >> > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > >> > [3] > >> > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- > >> > ev2jRFUoVD34/edit?pli=1 > >> > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > >> > [5] https://datatracker.ietf.org/wg/ledbat/charter/ > > > >-- > >--- > >Toerless Eckert, eckert@cisco.com > >Cisco NSSTG Systems & Technology Architecture > >SDN: Let me play with the network, mommy! > > ________________________________________________________________ > Bob Briscoe, BT From mls.ietf@gmail.com Tue Oct 29 13:18:29 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D573511E80E9 for ; Tue, 29 Oct 2013 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+TdCIYuKewF for ; Tue, 29 Oct 2013 13:18:29 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAAD21F9DF3 for ; Tue, 29 Oct 2013 13:18:28 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id t10so173499eei.41 for ; Tue, 29 Oct 2013 13:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MIEQ3UwARS7SetX1PGeSjoYU7TzxNybEOljOFvSXXM4=; b=KsNkarM2DDjijNWD9eP+u4HrAMmxEK3r/64m26tbyQJvkP8JumKIGNQVJr84hRuFWQ ADjKTD0atp1ct7WSWzU1O52s+7ipbO3k02MhWHcZi0z1HmDTGPitG4Da2uAne+nlAcr7 ZA+Sb+maNgR7nXdRtELDJ0z2syVFE36OY0o+jPFDnJjOU8/YxRDu8jqYdVsN9GtlGms0 GZ9ysDeJWHbB+RkT7h9z+H1TSyMQdWS0UwifkyoY2EPSMmYgn0MeQgfhkB5n+fvpP5Ha Fn/AmTpYOmAMfGTkuS0AK0wXKi9QRuu8xJCd2DhhH0uUqtBR94P08Uqa4AdehEYcLgEC /NTA== X-Received: by 10.15.50.195 with SMTP id l43mr1479110eew.30.1383077908046; Tue, 29 Oct 2013 13:18:28 -0700 (PDT) Received: from [192.168.178.25] (port-92-202-1-131.dynamic.qsc.de. [92.202.1.131]) by mx.google.com with ESMTPSA id k7sm74364590eeg.13.2013.10.29.13.18.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 13:18:27 -0700 (PDT) Message-ID: <52701811.2020408@gmail.com> Date: Tue, 29 Oct 2013 21:18:25 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Linda Dunbar , "tsv-area@ietf.org" Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:18:29 -0000 Hi Linda, We have a full talk about QUIC which is not exactly HTTP but might get us some taste of the direction of HTTP. However, if there are specific things to discuss, I am more than open to discuss them. Martin On 10/24/2013 08:19 PM, Linda Dunbar wrote: > Martin and Spencer, > > Possible to include HTTP? More and more applications run HTTP, and many people believe that HTTP is the future of the transport protocol(s). > > Linda > >> -----Original Message----- >> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On >> Behalf Of Martin Stiemerling >> Sent: Wednesday, October 23, 2013 2:13 AM >> To: tsv-area@ietf.org >> Subject: Announcing the TSVAREA session on "Evolution of IETF Transport >> Protocols" @ IETF-88 >> >> Dear all, >> >> We would like to give time to the Transport Area to discuss any >> potential need to evolve the IETF transport protocols. >> >> There are a number of proposals discussed in the IETF and outside of >> the >> IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of >> TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. >> QUIC [3]), and also discussions about the congestion control approach >> to >> be used (e.g., delay-based [4], LEDBAT [5]). >> >> (We are fully aware that this list of proposals is incomplete) >> >> Spencer and I are planning a slot in the TSVAREA session at IETF 88 in >> Vancouver to discuss this topic. >> >> More information to come soon. >> >> Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested >> in contributing actively to the session. >> >> Thanks, >> >> Spencer and Martin, your TSV ADs. >> >> References >> [1] https://developers.google.com/speed/protocols/tcp-laminar >> [2] http://tools.ietf.org/html/draft-iyengar-minion-concept >> [3] >> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV- >> ev2jRFUoVD34/edit?pli=1 >> [4] https://datatracker.ietf.org/wg/rmcat/charter/ >> [5] https://datatracker.ietf.org/wg/ledbat/charter/ From wes@mti-systems.com Tue Oct 29 13:31:56 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7C21E80BF for ; Tue, 29 Oct 2013 13:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6AQqnMIxyKC for ; Tue, 29 Oct 2013 13:31:50 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id A058D11E814C for ; Tue, 29 Oct 2013 13:31:49 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9TKVfZF009083 for ; Tue, 29 Oct 2013 16:31:41 -0400 Received: (qmail 24323 invoked by uid 0); 29 Oct 2013 20:31:41 -0000 X-TCPREMOTEIP: 107.45.126.23 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.126.23) by 0 with ESMTPA; 29 Oct 2013 20:31:40 -0000 Message-ID: <52701B25.8030603@mti-systems.com> Date: Tue, 29 Oct 2013 16:31:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , Linda Dunbar , "tsv-area@ietf.org" Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <52701811.2020408@gmail.com> In-Reply-To: <52701811.2020408@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:31:56 -0000 On 10/29/2013 4:18 PM, Martin Stiemerling wrote: > Hi Linda, > > We have a full talk about QUIC which is not exactly HTTP but might get > us some taste of the direction of HTTP. > > However, if there are specific things to discuss, I am more than open to > discuss them. > If there's anything to discuss about HTTP, it would relate to its needs from a transport protocol, as was done a bit at IETF87 and on mailing lists afterwards. HTTP itself isn't a transport protocol. People run over it in order to get through middleboxes and want to view it that way, but there are still real transport protocols underneath it (TCP, QUIC, etc). -- Wes Eddy MTI Systems From linda.dunbar@huawei.com Tue Oct 29 13:58:40 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2211E81B4 for ; Tue, 29 Oct 2013 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCdkm8Wbohvf for ; Tue, 29 Oct 2013 13:58:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E82511E819F for ; Tue, 29 Oct 2013 13:58:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXI70112; Tue, 29 Oct 2013 20:58:27 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 20:58:08 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 20:58:26 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 13:58:21 -0700 From: Linda Dunbar To: Wesley Eddy , Martin Stiemerling , "tsv-area@ietf.org" Subject: RE: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Thread-Topic: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Thread-Index: AQHO1OQNdzrxwiHmIEWp9+19dGe6mZoMl0aA//+OlHA= Date: Tue, 29 Oct 2013 20:58:20 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BF807E@dfweml509-mbx.china.huawei.com> References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <52701811.2020408@gmail.com> <52701B25.8030603@mti-systems.com> In-Reply-To: <52701B25.8030603@mti-systems.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.176] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:58:40 -0000 Here is my naive thinking of some improvement to be done at the transport l= ayer for HTTP. I say na=EFve because it could be totally not feasible. =20 More and more flows need to go through some additional functions (or treatm= ent) based on HTTP header (e.g. HTTP request or reply). But the HTTP header= is not fixed in the payload. There could be multiple HTTP headers in one = packet, or one HTTP message being carried by multiple packets. Therefore, i= t requires expensive DPI to filter packets with certain HTTP characteristic= s.=20 It would make life easier for network equipment if the TCP header has a few= bits to indicate the characteristics of HTTP message being carried. E.g. o= ffset to the HTTP header, the number of HTTP message in the packet, etc.=20 Linda > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com] > Sent: Tuesday, October 29, 2013 3:32 PM > To: Martin Stiemerling; Linda Dunbar; tsv-area@ietf.org > Subject: Re: Announcing the TSVAREA session on "Evolution of IETF > Transport Protocols" @ IETF-88 >=20 > On 10/29/2013 4:18 PM, Martin Stiemerling wrote: > > Hi Linda, > > > > We have a full talk about QUIC which is not exactly HTTP but might > get > > us some taste of the direction of HTTP. > > > > However, if there are specific things to discuss, I am more than open > to > > discuss them. > > >=20 >=20 > If there's anything to discuss about HTTP, it would relate to its > needs from a transport protocol, as was done a bit at IETF87 and > on mailing lists afterwards. >=20 > HTTP itself isn't a transport protocol. People run over it in order > to get through middleboxes and want to view it that way, but there are > still real transport protocols underneath it (TCP, QUIC, etc). >=20 > -- > Wes Eddy > MTI Systems From mls.ietf@gmail.com Tue Oct 29 14:02:35 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4C21F9A61 for ; Tue, 29 Oct 2013 14:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XHakkhl0NRO for ; Tue, 29 Oct 2013 14:02:34 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 898D521F99F8 for ; Tue, 29 Oct 2013 14:02:34 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b10so196848eae.38 for ; Tue, 29 Oct 2013 14:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=oNMt2JGcCKZehoIWdIhUcvDNCdUhqTxr2/IiDom5c4s=; b=Z4mAgzoKkadDWXfIOx+0jQsj2E2ZLPRqRffzc8KONvN7C6gXgg7ylG7FLbn8knUxd2 hPkEdJIUgmpaESaXD+5nMPHFyUbVm2Ped4xjT7LDJkxlzyXfSJB4CZ5warj6XTLROmAs tAp8uuu6OBhVIbnzck38jxFI0aQMtohA209JeEsjvukQ1cNR125LdCETC4ihcL9eZNpf PyjtRY3AmtBOzrp447PYsC2/okMCIJJSHoIuHPnrM3Hn3REODpUc/Y0dw3Abp4h/yA2U b9moGEJKztLI6zoSXSvZDGRjo/z5X9EBtUTkP90lBitI/+eHkNlYze6KK+5QlfTPWMVT s87Q== X-Received: by 10.14.223.3 with SMTP id u3mr124664eep.138.1383080543564; Tue, 29 Oct 2013 14:02:23 -0700 (PDT) Received: from [192.168.178.25] (port-92-202-1-131.dynamic.qsc.de. [92.202.1.131]) by mx.google.com with ESMTPSA id e13sm74761057eeu.4.2013.10.29.14.02.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 14:02:22 -0700 (PDT) Message-ID: <5270225D.8020806@gmail.com> Date: Tue, 29 Oct 2013 22:02:21 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "tsv-area@ietf.org" Subject: TSV AD "office hours" at IETF-88 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:02:35 -0000 Hi there, This is an early announcement of the TSV AD "office hours" at the IETF-88 meeting in Vancouver. The office hours are for the case there are things that you need to discuss with the Transport Area Directos in person and aren't able to pin us down any other time. The current time slot reserved for the office hours is 12:00 to 14:30 on Monday, November 4. The room will be announced soon. Thanks, Spencer & Martin From mls.ietf@gmail.com Thu Oct 31 10:56:56 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBF21E80F4 for ; Thu, 31 Oct 2013 10:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjOXc9hUye+G for ; Thu, 31 Oct 2013 10:56:55 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id D90AE11E8249 for ; Thu, 31 Oct 2013 10:56:50 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id d41so1545112eek.10 for ; Thu, 31 Oct 2013 10:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=m1wtSSidrahHoYz3fQ9wBN6T+D86T8dkmxPNxQGKQYU=; b=Yi0VQY0vGowHXasQ8UpEEg4kQYejn79xUKOW2BbzB9HhKuoYCUiRYWe3Rm7jJxhXAX yk2Q5Qf6BOXp/UgU24A1+IudBDs3qUUnMls9EILFqG3We75CWNu4CQ8TnGn079A7dWhq EKX+PAcSiMCRlH0Q3phd4DXAVoDS7zf3+Z2Ncsrw8g15djBx0Kg/x+r2ZHkUZ6+cpHsX pYQCFhlUI1RGu098cXV6CqG8MLHNuwsa4WQru+DKEPhp2Pbcll39V9T0oefQ2uiJ0LQt 4c185jdSCVmpVuO/7gsZvxaZR8yuf03Tem9TnhSCPEKR+OPthBPfYrsaPvyr9OOQm6AH blRA== X-Received: by 10.14.89.7 with SMTP id b7mr4550017eef.10.1383242203640; Thu, 31 Oct 2013 10:56:43 -0700 (PDT) Received: from [0.0.0.0] ([2001:1a80:2801:5200:3ccd:fdef:f631:cb1d]) by mx.google.com with ESMTPSA id d7sm11413959eem.8.2013.10.31.10.56.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 10:56:42 -0700 (PDT) Message-ID: <527299D8.10705@gmail.com> Date: Thu, 31 Oct 2013 18:56:40 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Toerless Eckert , Linda Dunbar Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <20131024193152.GQ11229@cisco.com> In-Reply-To: <20131024193152.GQ11229@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:56:56 -0000 Hi Toerless, On 10/24/2013 09:31 PM, Toerless Eckert wrote: > Reminds me a bit of the situation early on in RMT. There where > so many proposal for the "one protocol will save the world" that the WG > had to step back and first create a taxonomy of building block to > sort through the necessary/beneficial functions in them and only after > that was done try to compose full-protocol recommendations. I don't see that we need one protocol that saves the world, but we might need to push some protocols forward or not. > > Aka: would be lovely if this effort could lead to some useful taxonomy > of network conditions and components driving the innovations. That could be one possible outcome, as well as, that no changes are required. > > I am a bit cynical here, because if i look at the overall scope of > stuff going on (not specifically the ones proposed to be talked about), > what i see is this (yes, some pessimistic blinders used): > > 60% workaround to get through NAT/FW with a transport flow > 10% workaround to get QoS without having QoS in the network > 10% workarounds to use multiple interfaces without having mobile IP > 10% workarounds to make new congestion control compete with the > dumbest TCP stack and stupiest queue. > 9% workarounds to do transport stuff inside the app as opposed to > traditionally the OS because OS stacks are also considered inagile. > 1% all the other cool stuff SCTP had already try to aggregate but > re-done in the context of the above workarounds. > > So, the evolution of transport protocols i see is this architecture: > > -> the network is a bunch of bad packet forwarders with a lot of NAT/FW, > no DiffServ or other QoS, not even good AQM, no mobility, but a lot > of congestion by badly behaving transport stacks. That's what we have by today. > -> The OS likewise is not agile enough to deploy innovation. I'm not sure about this end, or it depends on how agile you are talking about. E.g., MPTCP seems to make it ways into OSes. > -> In-Middleware/App- Transport stacks to the rescue with all the above > inside the transport stack, designed only against the lowest common > denominator. We hopefully do not need up there eventually, though there are movements towards this. This is one reason to make this session, i.e., are we doing right or are we missing something. > > I totally get the business need that tranport stacks must do these workarounds, > even if it's just for the bottom 20% paths/subscribers of interest. But > what we have is overwhelmingly a focus on ONLY this bottom 20%, and little > in the transport stacks that balances expectations. If you bring in MUSTs > for workarounds at the bottom, i think the same spec MUST also include the > appropriate improvements for the top. Otherwise the market dynamics will > just continue to cause a race to the bottom and the title of the slot should > be: > > "Evolution of transport stacks - Rewarding bad networks and OS" I agreed that we should not optimize for one fraction :) Martin From mls.ietf@gmail.com Thu Oct 31 10:57:14 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2874411E823D for ; Thu, 31 Oct 2013 10:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAxTG9TawUB1 for ; Thu, 31 Oct 2013 10:57:13 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7027111E8170 for ; Thu, 31 Oct 2013 10:57:01 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so1921440eek.15 for ; Thu, 31 Oct 2013 10:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wqNrAImo1cQTFgljKxXzpmzcOYz8WIgBSZHISwDJEFM=; b=sSOlOdSBadKBTeU7R7cvlytej4TklTj+n5c/J2D8I3GxghM7pS21zjRcfjtZQYTP59 KI4Z/XK8PoELoA9570Pj5KvP/Vw6anjlyUZgts+fGE6VWkilgEbi1dw6HJTc6VPLnO0S bK9nLumNR2g1ThjgUHrLFtRscdRuSYbNwMpVr8BhcvM1MSofsMbN1VFvAgIW0/YwAqYL w45qWhuA2w4yZ+EvOLwhagIQJWWLSeLxMIgWyYIhjqwSbbGOTLWwBQhUU1dOK7f8wG1N 44V8jt/DERbPcs/HYgVUkDKihoZcIqCBJGWFtDfJXYe0fwHKZ9DDbjScLLROTj1qxFx+ tQsA== X-Received: by 10.14.5.3 with SMTP id 3mr4476299eek.49.1383242220524; Thu, 31 Oct 2013 10:57:00 -0700 (PDT) Received: from [0.0.0.0] ([2001:1a80:2801:5200:3ccd:fdef:f631:cb1d]) by mx.google.com with ESMTPSA id m54sm11454423eex.2.2013.10.31.10.56.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 10:56:59 -0700 (PDT) Message-ID: <527299E9.90704@gmail.com> Date: Thu, 31 Oct 2013 18:56:57 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Linda Dunbar , Wesley Eddy , "tsv-area@ietf.org" Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <52701811.2020408@gmail.com> <52701B25.8030603@mti-systems.com> <4A95BA014132FF49AE685FAB4B9F17F645BF807E@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BF807E@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:57:14 -0000 On 10/29/2013 09:58 PM, Linda Dunbar wrote: > Here is my naive thinking of some improvement to be done at the > transport layer for HTTP. I say na�ve because it could be totally not > feasible. > > More and more flows need to go through some additional functions (or > treatment) based on HTTP header (e.g. HTTP request or reply). But the > HTTP header is not fixed in the payload. There could be multiple > HTTP headers in one packet, or one HTTP message being carried by > multiple packets. Therefore, it requires expensive DPI to filter > packets with certain HTTP characteristics. > > It would make life easier for network equipment if the TCP header has > a few bits to indicate the characteristics of HTTP message being > carried. E.g. offset to the HTTP header, the number of HTTP message > in the packet, etc. I don't see any need to make TCP specific to HTTP. Martin > > > Linda > >> -----Original Message----- From: Wesley Eddy >> [mailto:wes@mti-systems.com] Sent: Tuesday, October 29, 2013 3:32 >> PM To: Martin Stiemerling; Linda Dunbar; tsv-area@ietf.org Subject: >> Re: Announcing the TSVAREA session on "Evolution of IETF Transport >> Protocols" @ IETF-88 >> >> On 10/29/2013 4:18 PM, Martin Stiemerling wrote: >>> Hi Linda, >>> >>> We have a full talk about QUIC which is not exactly HTTP but >>> might >> get >>> us some taste of the direction of HTTP. >>> >>> However, if there are specific things to discuss, I am more than >>> open >> to >>> discuss them. >>> >> >> >> If there's anything to discuss about HTTP, it would relate to its >> needs from a transport protocol, as was done a bit at IETF87 and on >> mailing lists afterwards. >> >> HTTP itself isn't a transport protocol. People run over it in >> order to get through middleboxes and want to view it that way, but >> there are still real transport protocols underneath it (TCP, QUIC, >> etc). >> >> -- Wes Eddy MTI Systems From touch@isi.edu Thu Oct 31 11:09:14 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B6021F9DA0 for ; Thu, 31 Oct 2013 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.676 X-Spam-Level: X-Spam-Status: No, score=-103.676 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJnpWsx4YubM for ; Thu, 31 Oct 2013 11:08:59 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 50EC711E817F for ; Thu, 31 Oct 2013 11:07:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9VI6xpc009635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Oct 2013 11:07:00 -0700 (PDT) Message-ID: <52729C9D.5020204@isi.edu> Date: Thu, 31 Oct 2013 11:08:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , Linda Dunbar , Wesley Eddy , "tsv-area@ietf.org" Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645BE80CD@dfweml509-mbb.china.huawei.com> <52701811.2020408@gmail.com> <52701B25.8030603@mti-systems.com> <4A95BA014132FF49AE685FAB4B9F17F645BF807E@dfweml509-mbx.china.huawei.com> <527299E9.90704@gmail.com> In-Reply-To: <527299E9.90704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:09:14 -0000 On 10/31/2013 10:56 AM, Martin Stiemerling wrote: > > > On 10/29/2013 09:58 PM, Linda Dunbar wrote: >> Here is my naive thinking of some improvement to be done at the >> transport layer for HTTP. I say na�ve because it could be totally not >> feasible. >> >> More and more flows need to go through some additional functions (or >> treatment) based on HTTP header (e.g. HTTP request or reply). But the >> HTTP header is not fixed in the payload. There could be multiple >> HTTP headers in one packet, or one HTTP message being carried by >> multiple packets. Therefore, it requires expensive DPI to filter >> packets with certain HTTP characteristics. >> >> It would make life easier for network equipment if the TCP header has >> a few bits to indicate the characteristics of HTTP message being >> carried. E.g. offset to the HTTP header, the number of HTTP message >> in the packet, etc. > > I don't see any need to make TCP specific to HTTP. +1 Besides, DPI is meaningless as we shift to using HTTPS (as Google did since Sept 28, 2013). Joe From mls.ietf@gmail.com Thu Oct 31 11:13:37 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D31111E818A for ; Thu, 31 Oct 2013 11:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA5DnHHt9nS0 for ; Thu, 31 Oct 2013 11:13:36 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB0811E822D for ; Thu, 31 Oct 2013 11:13:32 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id c4so1554846eek.31 for ; Thu, 31 Oct 2013 11:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=K4beJhxPPfOPd2LgnCOx4lBWUdWH0tJYJfRWdQEha/s=; b=JtKn2fuztD6vm7e/KPEwUvS1mtzqGsBOCV6zSMVnV5WpukdUKM7Z9MHTcZ9SougT3r dok6qRsjW4dxfjXT1VthyfiFxCY+6B8oJWnIzTWvmR9dm+jcGW7iJKcPqwnsZLYu+be+ Gp/9CV+y6sBPrJ0tFgp+RCV8sR5y0JHYPP6mUigcvjKOWdpKHPpTP0UXTnU7aO17PFC5 GgZL7ut7SwJrUCioYCUa/sd+TsK3PKvUeRuWYWmhXSenjd8rRzKYzM/yMxHk2Ycsz5Ow y/O92s5O1LtVho0svn/Fmvyg+KrsmA0ynKWZzGcdLtpBzBG6BnsuKHVoZlmQDjsLsvMn r04w== X-Received: by 10.14.115.133 with SMTP id e5mr4522791eeh.27.1383243211320; Thu, 31 Oct 2013 11:13:31 -0700 (PDT) Received: from [0.0.0.0] ([2001:1a80:2801:5200:3ccd:fdef:f631:cb1d]) by mx.google.com with ESMTPSA id d7sm11620373eem.8.2013.10.31.11.13.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 11:13:30 -0700 (PDT) Message-ID: <52729DC8.4090104@gmail.com> Date: Thu, 31 Oct 2013 19:13:28 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> In-Reply-To: <526776F0.50401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:13:37 -0000 Hi all, As promised a few more words about this part of the TSVAREA session in Vancouver: The intention of this "Evolution of IETF Transport Protocols" part is to test the waters if the IETF transport protocols are 'on track' of what is needed by today's hosts and applications -- and what's happening in the network. There are a number of activities around, see below, that propose changes to, for instance, TCP, and also new transport protocol proposals. There is also an on-going collaboration between the Transport Area and the HTTPbis working group with respect to HTTP/2.0. We will tackle a few of the proposals in the session, but there is no restricition to those. Here they are in no particular order: - The Saratoga protocol & interesting things out of this for the evolution of transport protocols (Presenter: Wes Eddy) - Functional decomposition of the transport layer (Presenter: Jana Iyengar) - TCP Crypt (Presenter: Andre Bittau) - IETF-43 Requirements for Unicast Transport/Sessions (ruts) bof (Presenter: Spencer Dawkins) Not well that there is also a presentation about the QUIC protocol just before this discussion. Note even better: The session does not need to deliver answers to any question that comes up, but is solely intended as a starting point for further activites, if needed, or just to note that we have talked about it, but everything is just fine and we can carry on. Thank you, Martin On 10/23/2013 09:12 AM, Martin Stiemerling wrote: > Dear all, > > We would like to give time to the Transport Area to discuss any > potential need to evolve the IETF transport protocols. > > There are a number of proposals discussed in the IETF and outside of the > IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of > TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. > QUIC [3]), and also discussions about the congestion control approach to > be used (e.g., delay-based [4], LEDBAT [5]). > > (We are fully aware that this list of proposals is incomplete) > > Spencer and I are planning a slot in the TSVAREA session at IETF 88 in > Vancouver to discuss this topic. > > More information to come soon. > > Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested > in contributing actively to the session. > > Thanks, > > Spencer and Martin, your TSV ADs. > > References > [1] https://developers.google.com/speed/protocols/tcp-laminar > [2] http://tools.ietf.org/html/draft-iyengar-minion-concept > [3] > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?pli=1 > > [4] https://datatracker.ietf.org/wg/rmcat/charter/ > [5] https://datatracker.ietf.org/wg/ledbat/charter/ From scott.brim@gmail.com Thu Oct 31 11:20:32 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEF21E808D for ; Thu, 31 Oct 2013 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPkeG784jsvH for ; Thu, 31 Oct 2013 11:20:32 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 737A121E8102 for ; Thu, 31 Oct 2013 11:20:31 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id wp4so3499959obc.12 for ; Thu, 31 Oct 2013 11:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=w3SgxxY5BirIOxuvSdxq8UeUWu9KTQZE8UtBxlpexgc=; b=X6amCmCFO+24dHN4QUGsERB/GOwjGQ8Pav5sJltpJs056fE7oLaxgQySCBXJd3faDD uMi1zTeSfwzN4kyZLtwmHpRDinLXyuDTHzkIpRHkG/+EO97M3gseZYtc9ReC9mT7yu4a h8+j97uGyHpmxjxGVU90sBnCeMCsPY3nvJ1BKbMKtzBRKKezrtNus53BGZmYKmR+RYGY DfxOwnqKeAOVbInNyirodCJxfFlK5JXwqCs/vUCbVIPL5ybRYKaBL3i9UPm6uOSvWG36 EVnFl+l17K+en5533kcbbD/Yg1gz9Cy9Gy4UgzmWtNI4q+KhUvtA1e14RUYx1jdoM/v8 ofCA== X-Received: by 10.182.61.8 with SMTP id l8mr862950obr.88.1383243630939; Thu, 31 Oct 2013 11:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Thu, 31 Oct 2013 11:20:10 -0700 (PDT) In-Reply-To: <52729DC8.4090104@gmail.com> References: <526776F0.50401@gmail.com> <52729DC8.4090104@gmail.com> From: Scott Brim Date: Thu, 31 Oct 2013 14:20:10 -0400 Message-ID: Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 To: Martin Stiemerling Content-Type: multipart/alternative; boundary=e89a8fb1f1fe42955104ea0d8169 Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:20:33 -0000 --e89a8fb1f1fe42955104ea0d8169 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 31, 2013 at 2:13 PM, Martin Stiemerling wrote: > - TCP Crypt (Presenter: Andre Bittau) I laughed when I saw that. I suggest "tcpcrypt" as a title instead. --e89a8fb1f1fe42955104ea0d8169 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 31, 2013 at 2:13 PM, Martin Stiemerling <mls.ietf@gmail.com&g= t; wrote:

- TCP Crypt (Presenter: Andre Bittau)

I laughed when I saw that. =A0I suggest "tcp= crypt" as a title instead.=A0

--e89a8fb1f1fe42955104ea0d8169-- From touch@isi.edu Thu Oct 31 11:34:23 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D710211E824A for ; Thu, 31 Oct 2013 11:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXRx3umEWwRn for ; Thu, 31 Oct 2013 11:34:19 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25C11E822D for ; Thu, 31 Oct 2013 11:34:19 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9VIXlZ6017502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Oct 2013 11:33:47 -0700 (PDT) Message-ID: <5272A28B.7070609@isi.edu> Date: Thu, 31 Oct 2013 11:33:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , tsv-area@ietf.org Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <52729DC8.4090104@gmail.com> In-Reply-To: <52729DC8.4090104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:34:24 -0000 Martin (et al.) I continue to have grave concerns about additional presentations to the IETF by parties who squat on TCP option codepoints - in this case, TCP Crypt. Any presentation on TCP Crypt to TSV should start - and end - with how they intend to undo the damage they have already done by deploying code using an unassigned codepoint. I have raised this issue before, and it has still not been corrected: https://github.com/sorbo/tcpcrypt/blob/master/kernel/linux/tcpcrypt/tcp_crypt.h This situation needs to change before they should be given continued presence at the IETF IMO. Joe On 10/31/2013 11:13 AM, Martin Stiemerling wrote: > Hi all, > > As promised a few more words about this part of the TSVAREA session in > Vancouver: > > The intention of this "Evolution of IETF Transport Protocols" part is to > test the waters if the IETF transport protocols are 'on track' of what > is needed by today's hosts and applications -- and what's happening in > the network. > > There are a number of activities around, see below, that propose changes > to, for instance, TCP, and also new transport protocol proposals. There > is also an on-going collaboration between the Transport Area and the > HTTPbis working group with respect to HTTP/2.0. > > We will tackle a few of the proposals in the session, but there is no > restricition to those. Here they are in no particular order: > > - The Saratoga protocol & interesting things out of this for the > evolution of transport protocols (Presenter: Wes Eddy) > - Functional decomposition of the transport layer (Presenter: Jana Iyengar) > - TCP Crypt (Presenter: Andre Bittau) > - IETF-43 Requirements for Unicast Transport/Sessions (ruts) bof > (Presenter: Spencer Dawkins) > > > Not well that there is also a presentation about the QUIC protocol just > before this discussion. > > > Note even better: > The session does not need to deliver answers to any question that comes > up, but is solely intended as a starting point for further activites, if > needed, or just to note that we have talked about it, but everything is > just fine and we can carry on. > > Thank you, > > Martin > > On 10/23/2013 09:12 AM, Martin Stiemerling wrote: >> Dear all, >> >> We would like to give time to the Transport Area to discuss any >> potential need to evolve the IETF transport protocols. >> >> There are a number of proposals discussed in the IETF and outside of the >> IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of >> TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. >> QUIC [3]), and also discussions about the congestion control approach to >> be used (e.g., delay-based [4], LEDBAT [5]). >> >> (We are fully aware that this list of proposals is incomplete) >> >> Spencer and I are planning a slot in the TSVAREA session at IETF 88 in >> Vancouver to discuss this topic. >> >> More information to come soon. >> >> Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested >> in contributing actively to the session. >> >> Thanks, >> >> Spencer and Martin, your TSV ADs. >> >> References >> [1] https://developers.google.com/speed/protocols/tcp-laminar >> [2] http://tools.ietf.org/html/draft-iyengar-minion-concept >> [3] >> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?pli=1 >> >> >> [4] https://datatracker.ietf.org/wg/rmcat/charter/ >> [5] https://datatracker.ietf.org/wg/ledbat/charter/ From mls.ietf@gmail.com Thu Oct 31 11:50:36 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1011E8126 for ; Thu, 31 Oct 2013 11:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHe6AO14c9vZ for ; Thu, 31 Oct 2013 11:50:31 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B911E8195 for ; Thu, 31 Oct 2013 11:50:26 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id e51so1578637eek.40 for ; Thu, 31 Oct 2013 11:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CHRyrvHP4WDo8o0iLyeWepMUvrkABP6sP3buWOzDo2I=; b=blEb+gc6dJqxwKpTlPWZaOjTj+VZ4Wu6mvWixRN2I7l5SFwxrTEyJOfEMwqLgi9gQP KeWPBPW8CkG5wgUeyHcXsGqFmnuOVyIAAPtdWY4iHGS96kAQjxL/l1aJBfPlgtv1/Zat kShJ4b6fXwemPzaDXMgD2bnberK4E9yIsYoPJHnpvoGOzYgx20++5AS9N/t+ZuGhry6t UK3rcrY9Hb+zmu7g3DhWm7v8sZEw0s08WHNNl2BAnYtNxgj3XEbdNa6jNIpKP+tzCWOj QB/iyMDtpUA8XUAenDWn4rOfvbgsHUe2LObkZowTYMeUfLu359kYX2fzVnxi+OjrcZ8H GvXA== X-Received: by 10.15.33.198 with SMTP id c46mr653039eev.115.1383245422887; Thu, 31 Oct 2013 11:50:22 -0700 (PDT) Received: from [0.0.0.0] ([2001:1a80:2801:5200:3ccd:fdef:f631:cb1d]) by mx.google.com with ESMTPSA id d7sm12055555eem.8.2013.10.31.11.50.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 11:50:22 -0700 (PDT) Message-ID: <5272A66C.1070901@gmail.com> Date: Thu, 31 Oct 2013 19:50:20 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Scott Brim Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 References: <526776F0.50401@gmail.com> <52729DC8.4090104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:50:37 -0000 On 10/31/2013 07:20 PM, Scott Brim wrote: > On Thu, Oct 31, 2013 at 2:13 PM, Martin Stiemerling > wrote: > > - TCP Crypt (Presenter: Andre Bittau) > > > I laughed when I saw that. I suggest "tcpcrypt" as a title instead. oh yes, it should read tcpcrypt! and also Andrea Bittau. It's late over here... Thanks :) Martin From l.wood@surrey.ac.uk Thu Oct 31 16:46:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2521E812F for ; Thu, 31 Oct 2013 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.162 X-Spam-Level: X-Spam-Status: No, score=-5.162 tagged_above=-999 required=5 tests=[AWL=1.436, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJAwecC1tlif for ; Thu, 31 Oct 2013 16:45:54 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7321E813C for ; Thu, 31 Oct 2013 16:45:47 -0700 (PDT) Received: from [195.245.230.131:60776] by server-3.bemta-3.messagelabs.com id 77/A2-03862-AABE2725; Thu, 31 Oct 2013 23:45:46 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-8.tower-78.messagelabs.com!1383263145!30452073!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14340 invoked from network); 31 Oct 2013 23:45:46 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-8.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 31 Oct 2013 23:45:46 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.216]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 31 Oct 2013 23:45:45 +0000 From: To: , , Date: Thu, 31 Oct 2013 23:44:56 +0000 Subject: RE: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Thread-Topic: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88 Thread-Index: Ac7WZ99CaSzKYDlSRomm7J1tDsH3HgAK1Sqy Message-ID: <290E20B455C66743BE178C5C84F1240847E3E25DA0@EXMB01CMS.surrey.ac.uk> References: <526776F0.50401@gmail.com> <52729DC8.4090104@gmail.com>,<5272A28B.7070609@isi.edu> In-Reply-To: <5272A28B.7070609@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 23:46:12 -0000 You have grave concerns about crypt on Halloween? And you already have a stake in this issue? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf Of Jo= e Touch [touch@isi.edu] Sent: 31 October 2013 18:33 To: Martin Stiemerling; tsv-area@ietf.org Subject: Re: Announcing the TSVAREA session on "Evolution of IETF Transport= Protocols" @ IETF-88 Martin (et al.) I continue to have grave concerns about additional presentations to the IETF by parties who squat on TCP option codepoints - in this case, TCP Crypt. Any presentation on TCP Crypt to TSV should start - and end - with how they intend to undo the damage they have already done by deploying code using an unassigned codepoint. I have raised this issue before, and it has still not been corrected: https://github.com/sorbo/tcpcrypt/blob/master/kernel/linux/tcpcrypt/tcp_cry= pt.h This situation needs to change before they should be given continued presence at the IETF IMO. Joe On 10/31/2013 11:13 AM, Martin Stiemerling wrote: > Hi all, > > As promised a few more words about this part of the TSVAREA session in > Vancouver: > > The intention of this "Evolution of IETF Transport Protocols" part is to > test the waters if the IETF transport protocols are 'on track' of what > is needed by today's hosts and applications -- and what's happening in > the network. > > There are a number of activities around, see below, that propose changes > to, for instance, TCP, and also new transport protocol proposals. There > is also an on-going collaboration between the Transport Area and the > HTTPbis working group with respect to HTTP/2.0. > > We will tackle a few of the proposals in the session, but there is no > restricition to those. Here they are in no particular order: > > - The Saratoga protocol & interesting things out of this for the > evolution of transport protocols (Presenter: Wes Eddy) > - Functional decomposition of the transport layer (Presenter: Jana Iyenga= r) > - TCP Crypt (Presenter: Andre Bittau) > - IETF-43 Requirements for Unicast Transport/Sessions (ruts) bof > (Presenter: Spencer Dawkins) > > > Not well that there is also a presentation about the QUIC protocol just > before this discussion. > > > Note even better: > The session does not need to deliver answers to any question that comes > up, but is solely intended as a starting point for further activites, if > needed, or just to note that we have talked about it, but everything is > just fine and we can carry on. > > Thank you, > > Martin > > On 10/23/2013 09:12 AM, Martin Stiemerling wrote: >> Dear all, >> >> We would like to give time to the Transport Area to discuss any >> potential need to evolve the IETF transport protocols. >> >> There are a number of proposals discussed in the IETF and outside of the >> IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of >> TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g. >> QUIC [3]), and also discussions about the congestion control approach to >> be used (e.g., delay-based [4], LEDBAT [5]). >> >> (We are fully aware that this list of proposals is incomplete) >> >> Spencer and I are planning a slot in the TSVAREA session at IETF 88 in >> Vancouver to discuss this topic. >> >> More information to come soon. >> >> Let Spencer and me know at tsv-ads@tools.ietf.org if you are interested >> in contributing actively to the session. >> >> Thanks, >> >> Spencer and Martin, your TSV ADs. >> >> References >> [1] https://developers.google.com/speed/protocols/tcp-laminar >> [2] http://tools.ietf.org/html/draft-iyengar-minion-concept >> [3] >> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jR= FUoVD34/edit?pli=3D1 >> >> >> [4] https://datatracker.ietf.org/wg/rmcat/charter/ >> [5] https://datatracker.ietf.org/wg/ledbat/charter/=