Subject: congestion control? - (was Re: Appointment of a Transport Area Director)

From: Roger Jørgensen <[email-masked]>
Date: Mon, 4 Mar 2013 19:20:46 +0100

changed the subject ... and added a cc to some that might not follow ietf@

On Sun, Mar 3, 2013 at 1:50 PM, Eggert, Lars <[email-masked]> wrote:
> On Mar 3, 2013, at 13:37, Eric Burger <[email-masked]> wrote:
>> There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed.
>>
>> Since I believe neither is the case, it sounds like the IESG requirements are too tight.
>
> I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control.
>
> The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment.

I'll ask a rather basic question and hope someone will answer in an
educational way - Why is congestion control so important? And where
does it apply? ... :-)

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Mar 2013 13:44:39 -0500

>>>>> "rgensen" == rgensen  <Roger> writes:
    rgensen> I'll ask a rather basic question and hope someone will
    rgensen> answer in an educational way - Why is congestion control so
    rgensen> important? And where does it apply? ... :-)

The Transport Area has all of the groups that deal with transport
protocols that need to do congestion control.   Further, the (current)
split of work means that all of the groups that need congestion
oversight would be cared for by the position that is currently becoming
empty as Wes leaves.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Bob Braden <[email-masked]>
Date: Mon, 04 Mar 2013 11:03:07 -0800

> educational way - Why is congestion control so important? And where 

Ouch. Because without it (as we learned the hard way in the late 1980s) \
the Internet may collapse and provide essentially no service.

It applies to everyone who sends packets into the Internet, potentially. 
OTOH, it is
a collective phenomenon; as long as most Internet users are using TCP, 
it does not
matter much what an individual non-TCP user does. TCP comes with the Gold
Standard congestion control.

Maybe the IETF could and should invite Van Jacobson to attend ab IETF 
meeting to
reprise one of his talks from 20 years ago.

Bob Braden

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 01:41:35 +0100 (CET)

> the Internet may collapse and provide essentially no service.
 
It is PR like this one:

  http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html

That gets me worried about folks might try to "fix" the internet
mostly due to the fact that they really haven't understood what
is already there any why.

-Martin

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 5 Mar 2013 07:52:56 +0000

> oversight would be cared for by the position that is currently becoming

Also, other areas frequently build protocols that need review from a congestion control perspective (do they back of under loss, can they even detect loss, etc.)

Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot.

Lars

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Mar 2013 10:54:37 +0100

Roger,

> educational way - Why is congestion control so important? And where

That basic question is a very important one to ask from time to time. 
Others have already answered, and I will simply add one addition: the
way one implements congestion control (or not) has impact not only on
the party or parties with whom your computer is speaking, but on every
communication that shares the links between your computer and those
parties.  So: get it wrong and you can hurt others.  And it's easy to
get wrong.

Eliot

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 5 Mar 2013 11:55:32 +0000

I've no idea about the example quoted, but I can see some of their motivation.

TCP's assumptions (really simplified) that loss of packet = congestion => backoff
aren't necessarily so in a wireless network, where packets can be lost without
congestion. This means that TCP into, out of, or across, a MANET using TCP can be
bad. It then tends to happen that the MANET people don't fully understand TCP,
and the TCP people don't fully understand MANETs.

I don't have a single good reference for what I say above, in particular have
things got better (or worse) as TCP evolves, and therefore which references
are still valid? But the obvious Google search (TCP MANET) throws up various
discussions.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: 05 March 2013 00:42
To: [email-masked]
Cc: [email-masked]
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director)

It is PR like this one:

-Martin

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: <[email-masked]>
Date: Tue, 5 Mar 2013 12:22:50 +0000

The problem with the congestion/interference and corruption problem is that error notification does
not percolate up the stack.

If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints,
TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost...
first hops benefit most. 

in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does.

And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie
some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow.

And to make the header checks pass with a chance of decoding the headers have to  be coded better than the payloads - and
this applies at each layer, recursively. um.

But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums.
And a paucity of available state to track and associate with flows.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dearlove, Christopher (UK) [[email-masked]]
Sent: 05 March 2013 11:55
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: congestion control? - (was Re: Appointment of a Transport  Area    Director)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: 05 March 2013 00:42
To: [email-masked]
Cc: [email-masked]
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director)

It is PR like this one:

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Mar 2013 14:15:59 +0000

> and the TCP people don't fully understand MANETs.

The effects you mention were definitely discussed in PILC.
http://www.ietf.org/wg/concluded/pilc.html
Maybe the PILC documents need revision?

    Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 05 Mar 2013 09:40:00 -0600

> Maybe the PILC documents need revision?

TRIGTRAN tried to nail this down in more detail after PILC concluded (I 
co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 
minutes pretty much captured where that ended up:

<quote>
Spencer summarized a private conversation with Mark Allman as, "Gee, 
maybe TCP does pretty well often times on its own.  You may be able to 
find cases where you could do better with notifications, but by the time 
you make sure the response to a notification doesn't have undesirable 
side effects in other cases, TCP doesn't look so bad"
</quote>

If we had to have all the TCP responding-to-loss mechanisms in an 
implementation anyway, and we could tell a sender to slow down, but not 
to speed up, it wasn't clear that additional mechanisms would buy you much.

References are at
http://www.ietf.org/proceedings/55/239.htm and
http://www.ietf.org/proceedings/56/251.htm

The high order bit on this may have been that TRIGTRAN wasn't IETF-ready 
and should have gone off to visit IRTF-land, but in the early 2000s, I 
(at least) had no idea how to make that happen.

Spencer

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 05 Mar 2013 14:40:35 -0500

> (at least) had no idea how to make that happen.

Later on, there was also a proposed TERNLI BoF and mailing list,
and bar BoF that resulted in:
http://tools.ietf.org/id/draft-sarolahti-tsvwg-crosslayer-01.txt
But didn't go any farther, that I'm aware of.  Section 6 actually
puts into context TRIGTRAN and other attempts to do something in
this space.  There's quite a bit of history just in the IETF.

RFC 4907 (IAB's "Architectural Implications of Link Indications")
is also a good snapshot of the thinking at that time.

-- 
Wes Eddy
MTI Systems

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 5 Mar 2013 12:01:20 -0800

> are still valid? But the obvious Google search (TCP MANET) throws up various

In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop
the packet, by design.  It will just delay the packet as it gets
resent through various checkpoints and goes through various rounds of
FEC.  The result is delay, TCP penalties that assume delay is loss,
... the end result is that every 3GPP network in the world (guessing)
has proxies in place to manipulate TCP so that when you go to
speedtest.net your $serviceprovider looks good.  Is this good
cross-layer optimization, no... but this is how it is.

So, fundamentals of CC and TCP have resulted in commercial need for
middleboxes in the core of the fastest growing part of the internet.
This is sometimes known as "tcp optmization" or "WAN acceleration",
both murky terms.

The issues in CC result is the re-invention of congestion control at
higher layers like http://en.wikipedia.org/wiki/QUIC

And, fun things like draft-ietf-rtcweb-data-channel

CB

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 05 Mar 2013 15:25:32 -0500

> This is sometimes known as "tcp optmization" or "WAN acceleration",

There may be some things the IETF can do to improve this.  It's not
clear yet, but some of the relevant vendors are participating in a
non-WG mailing list, focused on one aspect of the situation (TCP
option numbers), but recently more ambitious work was suggested:
http://www.ietf.org/mail-archive/web/middisc/current/msg00121.html

People who are interested in this, should *definitely* self-organize
a bit and think about a BoF, in my opinion.

-- 
Wes Eddy
MTI Systems

---

From: t.p. <[email-masked]>
Date: Wed, 6 Mar 2013 08:36:02 +0000

----- Original Message -----
From: "Cameron Byrne" <[email-masked]>
To: "Dearlove, Christopher (UK)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 05, 2013 8:01 PM
> I've no idea about the example quoted, but I can see some of their
motivation.

<snip>

<tp>
Interesting, there is more life in Congestion Control than I might have
thought.  But it begs the question, is this something that the IETF
should be involved with or is it better handled by those who are
developping LTE etc?  (It is true that the IETF did TCP without any skin
in X.25, 802.3 and so on but this sounds different).

Alternatively, when the ICCRG was looking for things to do, I did raise
the question of how true it was that (presumed) packet loss was due to
congestion (a fundamental assumption of the IETF) and got the impression
that that was regarded as an answered question and not a topic for
research.  From what you say, it sounds more as if the ICCRG should have
been looking at it.

Tom Petch

CB

http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.ht
ml

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Mar 2013 09:03:40 +0000

On 06/03/2013 08:36, t.p. wrote:
...
> developping LTE etc?  

>From the little I know about TCP proxies, they are horrible beasts
that can impact application layer semantics. Figuring out how to deal
with mixed e2e paths (partly lossy, partly congested) seems to me
very much an IRTF/IETF topic, even if we don't have an AD who is
a subject matter expert.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 06 Mar 2013 20:37:57 +0900

Cameron Byrne wrote:

> the packet, by design.

According to the end to end argument, that's simply impossible,
because intermediate equipments holding packets not confirmed
by the next hop may corrupt the packets or suddenly goes down.

 > It will just delay the packet as it gets
> FEC.  The result is delay,

Even with moderate packet drop probability, it means *A LOT OF* delay
or connection oriented communication, either of which makes 3GPP
mostly unusable.

						Masataka Ohta

---

From: <[email-masked]>
Date: Wed, 6 Mar 2013 11:43:55 +0000

3GPP has to never drop a packet because it's doing zero-header compression. Lose a bit, lose everything.

And ROHC is an IETF product.

I'm pretty sure the saving on headers is more than made up for in FEC, delay, etc. Not the engineering tradeoff one might want.

Lloyd Wood

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Masataka Ohta [[email-masked]]
Sent: 06 March 2013 11:37
To: [email-masked]
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area     Director)

                                                Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 06 Mar 2013 21:49:01 +0900

[email-masked] wrote:

> 3GPP has to never drop a packet because it's doing zero-header
> compression.

"has to never"? Even though it must, when it goes down.

> Lose a bit, lose everything.

You totally deny FEC. Wow!!!

> I'm pretty sure the saving on headers is more than made up for in
> FEC, delay, etc. Not the engineering tradeoff one might want.

It has nothing to do with congestion, not at all.

						Masataka Ohta

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Mar 2013 08:12:25 -0800

> very much an IRTF/IETF topic, even if we don't have an AD who is

There is a huge cross layer optimization issue between 3gpp and the ietf.
It is worse than you can imagine, highly akin to how the industry moved
passed the ietf with Nat. The same thing is happening with tcp.  Tcp is
simply not fit for these high latency high jitter low loss networks.

Google is a player in the e2e space for various business reasons and it
appears they are now in an arms race with these horrible mobile carrier
proxies (which in many cases do on the fly transcoding of video).

There are 2 fronts. 1 is quic as linked above. Another is their own
transcoding https proxy
https://developers.google.com/chrome/mobile/docs/data-compression

This is not novel. Opera mini has been doing this for years, otherwise know
as opera turbo. Oh, and Nokia has been doing it too.  They even help by
bypassing pki and any sense of internet security.

http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799

Hold on to your hats.

CB

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Mar 2013 16:30:02 +0000

See also:  http://www.akamai.com/html/about/press/releases/2012/press_091312.html

Irrespectively Yours,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Wednesday, March 06, 2013 8:12 AM
To: Brian E Carpenter
Cc: [email-masked]; IETF-Discussion
Subject: Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)

> very much an IRTF/IETF topic, even if we don't have an AD who is

There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp.  Tcp is simply not fit for these high latency high jitter low loss networks.

Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video).

There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression

This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too.  They even help by bypassing pki and any sense of internet security.

Hold on to your hats.

CB

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 07 Mar 2013 08:01:00 +0900

> See also:  http://www.akamai.com/html/about/press/releases/2012/press_091312.html

It seems to me that Akamai is doing things which must be
banned by IETF.

	Akamai IP Application Accelerator
	http://www.atoll.gr/media/brosures/FS_IPA.pdf
	Packet Loss Reduction
	Application performance is also affected
	by packet loss, which may be particularly
	troublesome when traffic traverses
	international network paths. IP Application
	                             ^^^^^^^^^^^^^^
	Accelerator uses a variety of advanced
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	packet loss reduction techniques, including
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	forward error correction and optional packet
	^^^^^^^^^^^^^^^^^^^^^^^^
	replication to eliminate packet loss.

						Masataka Ohta

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Mar 2013 20:08:26 -0800

Martin,

An article like this is the best reason why we should never finally resolve the
buffer bloat issue: Doing that would take away the opportunity for
generations of researcher to over and over regurgitate the same proposed
improvements and gain PhDs in the process.

I mean the Internet wold be like math without fermats last theorem.
Have you seen how disenfranchised mathematicians are now ? Its worse than the mood at
Kennedy Space center without a shuttle program (to bring the discussion back to
relevant aspects of IETF Orlando).

Sorry. could'nt resist.

I was actually happy about using some of those UDP based flow control reliable
transports in past years when i couldn't figure out how to fix the TCP stack of
my OSs. Alas, the beginning of the end of TCP is near now anyhow with RTCweb deciding
to use browser/user-level based SCTP over UDP stacks instead of OS-level TCP. 

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Mar 2013 20:20:11 -0800

> Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot.

Sure, but that could equally well be seen as a problem of the way how the
IESG chooses to perform its business. There are enough experts that
could consult whether its in role of directorates or else. They may just
not want to take on an AD role.

And there are a lot more TSV friction points with whats going on in the IETF
than just CC.

---

From: t.p. <[email-masked]>
Date: Thu, 7 Mar 2013 09:52:43 +0000

----- Original Message -----
From: "Cameron Byrne" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>; "IETF-Discussion" <[email-masked]>; "Dearlove,
Christopher (UK)" <[email-masked]>; "t.p."
<[email-masked]>
Sent: Wednesday, March 06, 2013 4:12 PM
> simply not fit for these high latency high jitter low loss networks.

Reading this reminds me that my first experience with TCP was over a
high latency high jitter network with 0% error and 0% loss (to my
ability to measure it) with retransmission rates of 50%, because the TCP
algorithms were totally unsuited to such a network.  It was, of course,
X.25.

Did anyone find a solution back then, or did we just wait for X.25 to be
superseded?

(I am back on my thesis that there is nothing new in Congestion Control,
that the principles and practices that we need have been around for many
years and that we just need to find them).

Tom Petch

> bypassing pki and any sense of internet security.
http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the
-middle-attacks-103799