Subject: [Iccrg] Fwd: 66th IETF - TERNLI BOF Cancelled
From: [email-masked] (Lars Eggert)
Date: Wed Jun 28 17:20:19 2006

Begin forwarded message:
> From: IETF Agenda <[email-masked]>
> Date: June 28, 2006 4:24:42 PM GMT+02:00
> To: IETF Announcement list <[email-masked]>
> Subject: 66th IETF - TERNLI BOF Cancelled
>
> The TERNLI BOF session scheduled for Monday at 1520-1720 has been  
> cancelled.
>
> BOF preparations were much more elaborate than initially estimated,  
> due to the
> complex problem space that this BOF targeted. Because a poor BOF is  
> worse than
> no BOF, the organizers have decided to postpone TERNLI until the  
> San Diego
> meeting. This will give the interested parties more time to prepare  
> for a
> successful session.
>
> In order to attract additional people interested in this topic,	the  
> Montreal
> TSVAREA  and INTAREA meetings will have a short talk on the overall  
> problem
> space.
>
> TSV and INT ADs

-- 
Lars Eggert                                     NEC Network Laboratories

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060628/605621cc/smime.bin

From: [email-masked] (Radek Krzywania)
Date: Fri Jun 16 10:47:25 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <op.ta60cq1mzxx9ui@dbr0q12j> <[email-masked]>
Message-ID: <op.ta8s2wwuzxx9ui@dbr0q12j>

>
> Stanislav Shalunov pointed me to this document the other day:
> http://transport.internet2.edu/transport-design-space.pdf
> (also in our wiki)
>
> - and I think that this might be the best starting point. It's
> exactly what we need - a classification of approaches, outlining
> the design space...
>
> right?

Hi Michael,
yes, I agree with you. That paper is also a good thing to start. It  
contains a really good overview across current solution approaches.

Best regards
Radek

-- 
______________________________________________________________________
Radoslaw Krzywania       Network Research and Development
[email-masked]      Poznan Supercomputing and Networking Center
+48 61 858 20 28         http://www.man.poznan.pl
______________________________________________________________________

From: [email-masked] (Michael Welzl)
Date: Fri Jun 16 10:32:39 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <op.ta60cq1mzxx9ui@dbr0q12j>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <op.ta60cq1mzxx9ui@dbr0q12j>
Message-ID: <[email-masked]>

On Thu, 2006-06-15 at 17:09, Radek Krzywania wrote:
> > I believe that a short but sharply focused document on approaches to cc  
> > would be extremely valuable for network
> > designers to explore new ways of dealing with congestion in next  
> > generation networks.
> 
> Hi all
> I was tracking the recent discussion on the list, and I agree with Doan.  
> Large number of papers does not improve the current knowledge and are not  
> worth of anylising them in details. It is much better to deal with  
> approaches. I guess there are lot of web pages/papers which tries to  

I like this a lot; indeed, if you look at the GGF document
I co-edited: http://www.welzl.at/research/publications/GFD.55.pdf
it's lengthy, but I'm not so sure if there's much general
congestion control related knowledge that one could learn from
it. I'd hesitate to simply repeat that process here.

I think that the way to do it is to start with an approach
based classification, and mention example mechanisms that
show that this particular approach can work.

e.g.: "methods with additional implicit feedback" / "delay"
      with Vegas and FAST as example schemes.

> compare the approaches and describe them, but I'd like to intorduce yet  
> another page with short algorithms description:
> http://kb.pert.switch.ch/cgi-bin/twiki/view/PERTKB/TransmissionControlProtocol

Thanks, I put it in the wiki.

> You may find there a quite "human readable" descriptions, including main  
> TCP approaches. I'am sure that much details are lack there, but I think it  
> may be a good start anyway.

Stanislav Shalunov pointed me to this document the other day:
http://transport.internet2.edu/transport-design-space.pdf
(also in our wiki)

- and I think that this might be the best starting point. It's
exactly what we need - a classification of approaches, outlining
the design space...

right?

Cheers,
Michael

From: [email-masked] (Radek Krzywania)
Date: Thu Jun 15 11:29:51 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <op.ta60cq1mzxx9ui@dbr0q12j>

> I believe that a short but sharply focused document on approaches to cc  
> would be extremely valuable for network
> designers to explore new ways of dealing with congestion in next  
> generation networks.

Hi all
I was tracking the recent discussion on the list, and I agree with Doan.  
Large number of papers does not improve the current knowledge and are not  
worth of anylising them in details. It is much better to deal with  
approaches. I guess there are lot of web pages/papers which tries to  
compare the approaches and describe them, but I'd like to intorduce yet  
another page with short algorithms description:
http://kb.pert.switch.ch/cgi-bin/twiki/view/PERTKB/TransmissionControlProtocol
You may find there a quite "human readable" descriptions, including main  
TCP approaches. I'am sure that much details are lack there, but I think it  
may be a good start anyway.

Regards
RAdek

-- 
______________________________________________________________________
Radoslaw Krzywania       Network Research and Development
[email-masked]      Poznan Supercomputing and Networking Center
+48 61 858 20 28         http://www.man.poznan.pl
______________________________________________________________________

From: [email-masked] (Doan B. Hoang)
Date: Thu Jun 15 09:12:09 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Generally I believe this is a good way to move forward. However, I also 
want to see what exactly is the goal
of the exercise.
Over the years, there have been numerous papers on congestion control 
and they all stemmed from
a small number of approaches. For example, hundreds of papers were 
written on TCP congestion control and
many of these are just useless variations of the basic TCP cc. There is 
little point in reviewing all these!

I believe that it will be more valuable for us to focus on these small 
number of approaches (explicit feedback, implicit feedback,
application layer cc, transport layer cc, data link layer cc, etc.).
Identify these approaches is not quite simple as it looks, but I believe 
that there are many experts in this group and we
will be able to do it well.

I believe that a short but sharply focused document on approaches to cc 
would be extremely valuable for network
designers to explore new ways of dealing with congestion in next 
generation networks.

Cheers,
Doan Hoang

Michael Welzl wrote:

>On Wed, 2006-06-14 at 14:42, Wesley Eddy wrote:
>  
>
>>On Tue, Jun 13, 2006 at 11:36:01PM +0200, Michael Welzl wrote:
>>    
>>
>>>>For the CC-related RFCs, the TCP Roadmap already covers this ground (and
>>>>hopefully does so pretty well).  To me it does not seem valuable for the
>>>>ICCRG to spend a lot of time rehashing this, or asking participants to
>>>>review another, different, book report of this same material.  The
>>>>relevent roadmap portions are:
>>>>http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html
>>>>        
>>>>
>>>As much as I like the roadmap, it is by no means a complete
>>>overview of congestion control related RFCs - it's strictly
>>>about TCP, with no mention of, e.g., multicast congestion
>>>control, DCCP, Active Queue Management (RFC2309), link layer
>>>interactions with congestion control...
>>>
>>>The way I looked at this document is that it would give
>>>an overview of congestion control work in the IETF *except*
>>>for the things that are in the roadmap already (and that
>>>it would of course point to the roadmap as the main reference
>>>on anything TCP related) - and this is more than you might
>>>expect - see my previous post:
>>>http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
>>>for an incomplete list.
>>>
>>>      
>>>
>>Ah, in that case, I do think this would be valuable to work on.  The list
>>of RFCs in that link contains a lot of overlap with the roadmap, and I
>>guess that was what confused me.
>>    
>>
>
>Sorry for that! This is just what I got by taking all the RFC
>and Internet-draft references from my book and removing
>everything that I considered "Standard TCP" - I didn't compare
>all these references, the list was just meant as a starting
>point.
>
>
>  
>
>>>>On the other hand, a document that itemizes and describes the more
>>>>radical congestion control algorithms would be valuable, and I think the
>>>>group should concentrate on this deliverable.  To my knowledge, the only
>>>>such algorithms that are currently described in RFCs are HighSpeed
>>>>and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
>>>>this area.
>>>>        
>>>>
>>>Do you still think that this should all be compiled
>>>in a single document in the light of what I said above?
>>>
>>>      
>>>
>>I don't think it matters.  Smaller documents might generate more reviews
>>from the group than a single giant document, but I don't think it's
>>significant one way or the other,
>>    
>>
>
>Ok - others? I'd just like to get some feedback before making
>this decision. The group is surprisingly silent. Speak up!
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>

-- 
Doan B. Hoang, PhD			Phone:(+61 2) 9514 7943
Department of Computer Systems		Fax:(+61 2) 9514 1807
Faculty of Information Technology	Email: [email-masked]
University of Technology, Sydney	
NSW 2007, AUSTRALIA		  URL: http://research.it.uts.edu.au/arn

From: [email-masked] (Michael Welzl)
Date: Wed Jun 14 18:09:52 2006
Subject: [Iccrg] ICCRG-related BOF in Montreal: Transport-Enhancing  Refinements to the Network Layer Interface (TERNLI)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I also think that discussing this together with ICCRG'ers
is a good idea (and another reason for them to get moving
a bit  :-)   ).

As for a presentation, I can't make it to Montreal - Keshav,
can you?

Cheers,
Michael

On Wed, 2006-06-14 at 09:07, Lars Eggert wrote:
> Hi,
> 
> please note that the TSV and INT areas are sponsoring the following  
> non-WG-forming BOF in Montreal. We'd welcome any input that ICCRG may  
> have on the scope or content of this BOF. We'd also be interested in  
> maybe seeing a short presentation from the congestion control  
> research community during the BOF.
> 
> Thanks,
> Lars
> 
> ----------------------------------------------------------------------
> 
> Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)
> (pronounce: "turn-ly")
> 
> BOF Chairs:
> <tbd>
> 
> Sponsoring Area Directors:
> Lars Eggert <[email-masked]>
> Magnus Westerlund <[email-masked]>
> Jari Arkko <[email-masked]>
> 
> Mailing List:
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/ternli
> Archive: http://www.ietf.org/mail-archive/web/ternli/index.html
> 
> 
> BACKGROUND
> 
> The communication abstraction provided by IP at the network layer  
> delivers packets in an unordered, unreliable manner and does not  
> protect against duplication. The users of this abstraction, i.e., the  
> transport protocols, have made additional assumptions about this  
> abstraction. Many of these assumptions are critical to the effective  
> operation of important transport mechanisms, such as congestion  
> control, flow control or reliability. These assumptions include, for  
> example, that hosts remain at network locations identified by an IP  
> address on timescales that are orders of magnitude larger than the  
> duration of a communication instance. Another such assumption is that  
> packets flowing from a source to a destination mostly follow the same  
> path and that changes to that path occur on timescales that are  
> several orders of magnitude larger than the RTT between the two  
> hosts. Similarly, transport mechanisms have assumed that the  
> characteristics of such paths, such as bandwidth, delay, reordering  
> and loss probabilities, also change on timescales much larger than  
> the RTT.
> 
> In the current Internet, many of these assumptions are no longer  
> generally true, because it has become much more dynamic in recent  
> years. Mobile hosts and whole subnetworks have started to move  
> between network locations on relatively short timescales. A growing  
> number of hosts is multi-homed, connected through multiple links with  
> possibly very different properties at the same time. The Internet has  
> incorporated new link technologies with characteristics that are much  
> more dynamic than in the past, due to functionality such as link- 
> layer retransmissions, adaptive coding or support for link-local  
> mobility.
> 
> Several extensions to the internal functionality of the network  
> layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication  
> in such dynamic environments. These extensions maintain the  
> traditional interface between network and transport layers, isolating  
> the transports from some of the dynamic effects present at and below  
> the network layer, similar to how transports remain unaware of  
> routing changes or packet fragmentation. They consequently allow  
> existing transport protocols to continue to operate without  
> modifications.
> 
> This isolation, however, comes at a cost, because the traditional  
> communication abstraction maintained by these new network-layer  
> extensions hides information that transport-layer protocols should  
> act on. Many common transport mechanisms for congestion window  
> estimation, RTT measurements or path MTU discovery are not agile  
> enough to properly handle the significant instantaneous changes to  
> path characteristics that these network-layer extensions introduce.  
> This can, in turn, decrease the effectiveness of important transport  
> mechanisms, such as congestion control. Consequently, although  
> existing transports can operate on top of these network-layer  
> extensions to some degree, their performance and efficiency decreases.
> 
> 
> SCOPE
> 
> This BOF brings together the INT and TSV communities to discuss how  
> this inter-area problem space can be successfully approached within  
> the IETF and IRTF. Consequently, detailed presentations of specific  
> technical proposals are out-of-scope for this BOF. The BOF will also  
> *not* lead to the formation of a working group. The goal is to give  
> interested parties a venue for discussing how this problem space  
> might be sliced.
> 
> The simple, general purpose interface between the network and  
> transport layers is one of the key features that has guaranteed the  
> evolvability of the Internet architecture, because it maintains the  
> independence of transport layers from functionality located below it,  
> and vice versa. Approaches for extending this core component must  
> therefore be broadly applicable and be of general usefulness. Point  
> solutions that optimize for specific deployment scenarios or  
> technologies are thus not relevant to this discussion.
> 
> 
> DISCUSSION MATERIAL
> 
> A possible approach might be to identify a generic, technology- 
> independent set of well-defined network- and lower-layer information  
> that has the potential to improve performance and operation of a  
> large number of different transport mechanisms and protocols and can  
> be provided in different ways by different specific underlying  
> mechanisms and technologies. This information must be optional, i.e.,  
> it might improve transport operation if present, but transports must  
> not depend on its presence.
> 
> One existing example of an extension that follows this general  
> approach is Explicit Congestion Notification (ECN). The ECN signal is  
> well-defined and can be provided in different ways by network-layer  
> mechanisms; transport protocols act on the signal independently of  
> where and how it was generated. Another example of such an extension  
> in this spirit is Quick-Start, were routers in the network explicitly  
> signal source hosts the available capacity along the path to their  
> destinations. Transport protocols can utilize this generic,  
> technology-independent, network-layer information in different ways  
> to improve operation and performance.
> 
> One approach forward may be to integrate these existing or proposed  
> mechanisms with additional, similar extensions that result in a  
> uniform extension to the current network-layer interface.
> 
> The BOF organizers are interested in soliciting additional approaches  
> that attempt to address this problem space.
> 
> 
> FURTHER READING
> 
> L. Eggert and W. Eddy. Towards More Expressive Transport-Layer  
> Interfaces. Under Submission, June 2006.
> http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf
> 
> B. Aboba (ed.) Architectural Implications of Link Indications.  
> Internet Draft draft-iab-link-indications-04, Work in Progress,  
> December 2005.
> http://tools.ietf.org/html/draft-iab-link-indications-04
> 
> K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit  
> Congestion Notification (ECN) to IP. RFC 3168, September 2001.
> http://tools.ietf.org/html/rfc3168
> 
> A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP  
> and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in  
> Progress, April 2006.
> http://tools.ietf.org/html/draft-ietf-tsvwg-quickstart-03
> 
> S. Schuetz, L. Eggert, W. Eddy, Y. Swami and K. Le. TCP Response to  
> Lower-Layer Connectivity-Change Indications. Internet Draft draft- 
> schuetz-tcpm-tcp-rlci-00, Work in Progress, May 2006.
> http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-00
> 
> J. Korhonen, S. Park, J. Zhang, C. Hwang and P. Sarolahti. Link  
> Characteristic Information for IP Mobility Problem Statement.  
> Internet Draft draft-korhonen-mobopts-link-characteristics-ps-01,  
> Work in Progress, June 2006.
> http://tools.ietf.org/html/draft-korhonen-mobopts-link- 
> characteristics-ps-01
-- 
Michael Welzl <[email-masked]>
University of Innsbruck

From: [email-masked] (Stephen Suryaputra)
Date: Wed Jun 14 16:41:31 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Michael,

I think such a document is a very good idea. I've been following this
list on and off, and congestion control is not my main area. So, this
will help me beat the learning curve.

In regard to the concern about the size, maybe we can put the document
into sections and solicit reviews individually.

Stephen

On 14 Jun 2006 14:57:18 +0200, Michael Welzl <[email-masked]> wrote:
> On Wed, 2006-06-14 at 14:42, Wesley Eddy wrote:
> > On Tue, Jun 13, 2006 at 11:36:01PM +0200, Michael Welzl wrote:
> > > > For the CC-related RFCs, the TCP Roadmap already covers this ground (and
> > > > hopefully does so pretty well).  To me it does not seem valuable for the
> > > > ICCRG to spend a lot of time rehashing this, or asking participants to
> > > > review another, different, book report of this same material.  The
> > > > relevent roadmap portions are:
> > > > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html
> > >
> > > As much as I like the roadmap, it is by no means a complete
> > > overview of congestion control related RFCs - it's strictly
> > > about TCP, with no mention of, e.g., multicast congestion
> > > control, DCCP, Active Queue Management (RFC2309), link layer
> > > interactions with congestion control...
> > >
> > > The way I looked at this document is that it would give
> > > an overview of congestion control work in the IETF *except*
> > > for the things that are in the roadmap already (and that
> > > it would of course point to the roadmap as the main reference
> > > on anything TCP related) - and this is more than you might
> > > expect - see my previous post:
> > > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
> > > for an incomplete list.
> > >
> >
> > Ah, in that case, I do think this would be valuable to work on.  The list
> > of RFCs in that link contains a lot of overlap with the roadmap, and I
> > guess that was what confused me.
>
> Sorry for that! This is just what I got by taking all the RFC
> and Internet-draft references from my book and removing
> everything that I considered "Standard TCP" - I didn't compare
> all these references, the list was just meant as a starting
> point.
>
>
> > > > On the other hand, a document that itemizes and describes the more
> > > > radical congestion control algorithms would be valuable, and I think the
> > > > group should concentrate on this deliverable.  To my knowledge, the only
> > > > such algorithms that are currently described in RFCs are HighSpeed
> > > > and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
> > > > this area.
> > >
> > > Do you still think that this should all be compiled
> > > in a single document in the light of what I said above?
> > >
> >
> > I don't think it matters.  Smaller documents might generate more reviews
> > from the group than a single giant document, but I don't think it's
> > significant one way or the other,
>
> Ok - others? I'd just like to get some feedback before making
> this decision. The group is surprisingly silent. Speak up!
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Michael Welzl)
Date: Wed Jun 14 15:18:33 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 2006-06-14 at 14:42, Wesley Eddy wrote:
> On Tue, Jun 13, 2006 at 11:36:01PM +0200, Michael Welzl wrote:
> > > For the CC-related RFCs, the TCP Roadmap already covers this ground (and
> > > hopefully does so pretty well).  To me it does not seem valuable for the
> > > ICCRG to spend a lot of time rehashing this, or asking participants to
> > > review another, different, book report of this same material.  The
> > > relevent roadmap portions are:
> > > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html
> > 
> > As much as I like the roadmap, it is by no means a complete
> > overview of congestion control related RFCs - it's strictly
> > about TCP, with no mention of, e.g., multicast congestion
> > control, DCCP, Active Queue Management (RFC2309), link layer
> > interactions with congestion control...
> >
> > The way I looked at this document is that it would give
> > an overview of congestion control work in the IETF *except*
> > for the things that are in the roadmap already (and that
> > it would of course point to the roadmap as the main reference
> > on anything TCP related) - and this is more than you might
> > expect - see my previous post:
> > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
> > for an incomplete list.
> >
> 
> Ah, in that case, I do think this would be valuable to work on.  The list
> of RFCs in that link contains a lot of overlap with the roadmap, and I
> guess that was what confused me.

Sorry for that! This is just what I got by taking all the RFC
and Internet-draft references from my book and removing
everything that I considered "Standard TCP" - I didn't compare
all these references, the list was just meant as a starting
point.

> > > On the other hand, a document that itemizes and describes the more
> > > radical congestion control algorithms would be valuable, and I think the
> > > group should concentrate on this deliverable.  To my knowledge, the only
> > > such algorithms that are currently described in RFCs are HighSpeed
> > > and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
> > > this area.
> > 
> > Do you still think that this should all be compiled
> > in a single document in the light of what I said above?
> >
> 
> I don't think it matters.  Smaller documents might generate more reviews
> from the group than a single giant document, but I don't think it's
> significant one way or the other,

Ok - others? I'd just like to get some feedback before making
this decision. The group is surprisingly silent. Speak up!

Cheers,
Michael

From: [email-masked] (Lars Eggert)
Date: Wed Jun 14 09:28:05 2006
Subject: [Iccrg] ICCRG-related BOF in Montreal: Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)
Message-ID: <[email-masked]>

Hi,

please note that the TSV and INT areas are sponsoring the following  
non-WG-forming BOF in Montreal. We'd welcome any input that ICCRG may  
have on the scope or content of this BOF. We'd also be interested in  
maybe seeing a short presentation from the congestion control  
research community during the BOF.

Thanks,
Lars

----------------------------------------------------------------------

Transport-Enhancing Refinements to the Network Layer Interface (TERNLI)
(pronounce: "turn-ly")

BOF Chairs:
<tbd>

Sponsoring Area Directors:
Lars Eggert <[email-masked]>
Magnus Westerlund <[email-masked]>
Jari Arkko <[email-masked]>

Mailing List:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/ternli
Archive: http://www.ietf.org/mail-archive/web/ternli/index.html

BACKGROUND

The communication abstraction provided by IP at the network layer  
delivers packets in an unordered, unreliable manner and does not  
protect against duplication. The users of this abstraction, i.e., the  
transport protocols, have made additional assumptions about this  
abstraction. Many of these assumptions are critical to the effective  
operation of important transport mechanisms, such as congestion  
control, flow control or reliability. These assumptions include, for  
example, that hosts remain at network locations identified by an IP  
address on timescales that are orders of magnitude larger than the  
duration of a communication instance. Another such assumption is that  
packets flowing from a source to a destination mostly follow the same  
path and that changes to that path occur on timescales that are  
several orders of magnitude larger than the RTT between the two  
hosts. Similarly, transport mechanisms have assumed that the  
characteristics of such paths, such as bandwidth, delay, reordering  
and loss probabilities, also change on timescales much larger than  
the RTT.

In the current Internet, many of these assumptions are no longer  
generally true, because it has become much more dynamic in recent  
years. Mobile hosts and whole subnetworks have started to move  
between network locations on relatively short timescales. A growing  
number of hosts is multi-homed, connected through multiple links with  
possibly very different properties at the same time. The Internet has  
incorporated new link technologies with characteristics that are much  
more dynamic than in the past, due to functionality such as link- 
layer retransmissions, adaptive coding or support for link-local  
mobility.

Several extensions to the internal functionality of the network  
layer, such as Mobile IP, NEMO, HIP or SHIM6, support communication  
in such dynamic environments. These extensions maintain the  
traditional interface between network and transport layers, isolating  
the transports from some of the dynamic effects present at and below  
the network layer, similar to how transports remain unaware of  
routing changes or packet fragmentation. They consequently allow  
existing transport protocols to continue to operate without  
modifications.

This isolation, however, comes at a cost, because the traditional  
communication abstraction maintained by these new network-layer  
extensions hides information that transport-layer protocols should  
act on. Many common transport mechanisms for congestion window  
estimation, RTT measurements or path MTU discovery are not agile  
enough to properly handle the significant instantaneous changes to  
path characteristics that these network-layer extensions introduce.  
This can, in turn, decrease the effectiveness of important transport  
mechanisms, such as congestion control. Consequently, although  
existing transports can operate on top of these network-layer  
extensions to some degree, their performance and efficiency decreases.

SCOPE

This BOF brings together the INT and TSV communities to discuss how  
this inter-area problem space can be successfully approached within  
the IETF and IRTF. Consequently, detailed presentations of specific  
technical proposals are out-of-scope for this BOF. The BOF will also  
*not* lead to the formation of a working group. The goal is to give  
interested parties a venue for discussing how this problem space  
might be sliced.

The simple, general purpose interface between the network and  
transport layers is one of the key features that has guaranteed the  
evolvability of the Internet architecture, because it maintains the  
independence of transport layers from functionality located below it,  
and vice versa. Approaches for extending this core component must  
therefore be broadly applicable and be of general usefulness. Point  
solutions that optimize for specific deployment scenarios or  
technologies are thus not relevant to this discussion.

DISCUSSION MATERIAL

A possible approach might be to identify a generic, technology- 
independent set of well-defined network- and lower-layer information  
that has the potential to improve performance and operation of a  
large number of different transport mechanisms and protocols and can  
be provided in different ways by different specific underlying  
mechanisms and technologies. This information must be optional, i.e.,  
it might improve transport operation if present, but transports must  
not depend on its presence.

One existing example of an extension that follows this general  
approach is Explicit Congestion Notification (ECN). The ECN signal is  
well-defined and can be provided in different ways by network-layer  
mechanisms; transport protocols act on the signal independently of  
where and how it was generated. Another example of such an extension  
in this spirit is Quick-Start, were routers in the network explicitly  
signal source hosts the available capacity along the path to their  
destinations. Transport protocols can utilize this generic,  
technology-independent, network-layer information in different ways  
to improve operation and performance.

One approach forward may be to integrate these existing or proposed  
mechanisms with additional, similar extensions that result in a  
uniform extension to the current network-layer interface.

The BOF organizers are interested in soliciting additional approaches  
that attempt to address this problem space.

FURTHER READING

L. Eggert and W. Eddy. Towards More Expressive Transport-Layer  
Interfaces. Under Submission, June 2006.
http://larseggert.de/papers/2006-ccr-transport-interfaces.pdf

B. Aboba (ed.) Architectural Implications of Link Indications.  
Internet Draft draft-iab-link-indications-04, Work in Progress,  
December 2005.
http://tools.ietf.org/html/draft-iab-link-indications-04

K. Ramakrishnan, S. Floyd and D. Black. The Addition of Explicit  
Congestion Notification (ECN) to IP. RFC 3168, September 2001.
http://tools.ietf.org/html/rfc3168

A. Jain, S. Floyd, M. Allman and P. Sarolahti. Quick-Start for TCP  
and IP. Internet Draft draft-ietf-tsvwg-quickstart-03, Work in  
Progress, April 2006.
http://tools.ietf.org/html/draft-ietf-tsvwg-quickstart-03

S. Schuetz, L. Eggert, W. Eddy, Y. Swami and K. Le. TCP Response to  
Lower-Layer Connectivity-Change Indications. Internet Draft draft- 
schuetz-tcpm-tcp-rlci-00, Work in Progress, May 2006.
http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-00

J. Korhonen, S. Park, J. Zhang, C. Hwang and P. Sarolahti. Link  
Characteristic Information for IP Mobility Problem Statement.  
Internet Draft draft-korhonen-mobopts-link-characteristics-ps-01,  
Work in Progress, June 2006.
http://tools.ietf.org/html/draft-korhonen-mobopts-link- 
characteristics-ps-01

-- 
Lars Eggert                                     NEC Network Laboratories

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3686 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060614/ba6479fa/smime-0001.bin
>From [email-masked]  Wed Jun 14 13:42:46 2006
From: [email-masked] (Wesley Eddy)
Date: Wed Jun 14 15:03:58 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jun 13, 2006 at 11:36:01PM +0200, Michael Welzl wrote:
> > For the CC-related RFCs, the TCP Roadmap already covers this ground (and
> > hopefully does so pretty well).  To me it does not seem valuable for the
> > ICCRG to spend a lot of time rehashing this, or asking participants to
> > review another, different, book report of this same material.  The
> > relevent roadmap portions are:
> > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html
> 
> As much as I like the roadmap, it is by no means a complete
> overview of congestion control related RFCs - it's strictly
> about TCP, with no mention of, e.g., multicast congestion
> control, DCCP, Active Queue Management (RFC2309), link layer
> interactions with congestion control...
>
> The way I looked at this document is that it would give
> an overview of congestion control work in the IETF *except*
> for the things that are in the roadmap already (and that
> it would of course point to the roadmap as the main reference
> on anything TCP related) - and this is more than you might
> expect - see my previous post:
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
> for an incomplete list.
>

Ah, in that case, I do think this would be valuable to work on.  The list
of RFCs in that link contains a lot of overlap with the roadmap, and I
guess that was what confused me.

> > On the other hand, a document that itemizes and describes the more
> > radical congestion control algorithms would be valuable, and I think the
> > group should concentrate on this deliverable.  To my knowledge, the only
> > such algorithms that are currently described in RFCs are HighSpeed
> > and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
> > this area.
> 
> Do you still think that this should all be compiled
> in a single document in the light of what I said above?
>

I don't think it matters.  Smaller documents might generate more reviews
from the group than a single giant document, but I don't think it's
significant one way or the other,

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Tue Jun 13 23:55:21 2006
Subject: AW: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Wesley,

> > Speaking of overviews, there was this recent discussion
> > about writing an overview of cc. related RFCs. I think
> > that we should proceed with this, and I also think that
> > we should write an overview of other cc. mechanisms. My
> > question to the group is: should these be two separate
> > documents or a single one?
> > 
> 
> For the CC-related RFCs, the TCP Roadmap already covers this ground (and
> hopefully does so pretty well).  To me it does not seem valuable for the
> ICCRG to spend a lot of time rehashing this, or asking participants to
> review another, different, book report of this same material.  The
> relevent roadmap portions are:
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html

As much as I like the roadmap, it is by no means a complete
overview of congestion control related RFCs - it's strictly
about TCP, with no mention of, e.g., multicast congestion
control, DCCP, Active Queue Management (RFC2309), link layer
interactions with congestion control...

The way I looked at this document is that it would give
an overview of congestion control work in the IETF *except*
for the things that are in the roadmap already (and that
it would of course point to the roadmap as the main reference
on anything TCP related) - and this is more than you might
expect - see my previous post:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
for an incomplete list.

> On the other hand, a document that itemizes and describes the more
> radical congestion control algorithms would be valuable, and I think the
> group should concentrate on this deliverable.  To my knowledge, the only
> such algorithms that are currently described in RFCs are HighSpeed
> and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
> this area.

Do you still think that this should all be compiled
in a single document in the light of what I said above?

Cheers,
Michael

From: [email-masked] (Wesley Eddy)
Date: Tue Jun 13 16:03:48 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jun 13, 2006 at 12:16:16PM +0200, Michael Welzl wrote:
> 
> Speaking of overviews, there was this recent discussion
> about writing an overview of cc. related RFCs. I think
> that we should proceed with this, and I also think that
> we should write an overview of other cc. mechanisms. My
> question to the group is: should these be two separate
> documents or a single one?
> 

For the CC-related RFCs, the TCP Roadmap already covers this ground (and
hopefully does so pretty well).  To me it does not seem valuable for the
ICCRG to spend a lot of time rehashing this, or asking participants to
review another, different, book report of this same material.  The
relevent roadmap portions are:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html

On the other hand, a document that itemizes and describes the more
radical congestion control algorithms would be valuable, and I think the
group should concentrate on this deliverable.  To my knowledge, the only
such algorithms that are currently described in RFCs are HighSpeed
and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
this area.
 
-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Katsushi Kobayashi)
Date: Tue Jun 13 13:31:15 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I believe single document is enough in this time.
If we decide to separate the document, the RG
contributions are also separated. The RG has not
been taken care in long-time. I believe we should
not split our "small" energy in this time.

We can split the document later, when we will decide
it.

--
Katsshi Kobayashi

On 2006/06/13, at 19:16, Michael Welzl wrote:

> Dear all,
>
> The first concrete step that we should take is to create
> an overview of current congestion control research. We
> really need to have the existing proposals documented
> somewhere in order to learn something (derive rules)
> from them.
>
> Keshav and I started with a small bibliography - a Wiki
> page that gives an overview of cc. overviews (a "meta"
> overview  :)   ), and we solicit input. See
> http://www1.tools.ietf.org/group/irtf/trac/wiki/ICCRG
>
> Speaking of overviews, there was this recent discussion
> about writing an overview of cc. related RFCs. I think
> that we should proceed with this, and I also think that
> we should write an overview of other cc. mechanisms. My
> question to the group is: should these be two separate
> documents or a single one?
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Tue Jun 13 12:38:23 2006
Subject: [Iccrg] Soliciting input for cc. bibliography
Message-ID: <[email-masked]>

Dear all,

The first concrete step that we should take is to create
an overview of current congestion control research. We
really need to have the existing proposals documented
somewhere in order to learn something (derive rules)
from them.

Keshav and I started with a small bibliography - a Wiki
page that gives an overview of cc. overviews (a "meta"
overview  :)   ), and we solicit input. See
http://www1.tools.ietf.org/group/irtf/trac/wiki/ICCRG

Speaking of overviews, there was this recent discussion
about writing an overview of cc. related RFCs. I think
that we should proceed with this, and I also think that
we should write an overview of other cc. mechanisms. My
question to the group is: should these be two separate
documents or a single one?

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Tue Jun 13 12:33:40 2006
Subject: [Iccrg] My thoughts on the group, and how to proceed
Message-ID: <[email-masked]>

Hi all,

First of all, let me apologize for remaining silent for
such a long time. I figure that this is not a good way
to start out as a group co-chair...  but we're approaching
the end of the semester here in Innsbruck, with increasing
organizational load. Also, I had some concerns about the
goals of this group, and I needed some time (plus a conf.
call  :)  ) to get a clear view of the picture.

THE DEPRESSING PAST:
====================

Consider a group of car designers, each standing next to
their cars. All of them have cars which are much better
than the "standard car"; the main company which builds
the standard car has only focused on making it more robust
over the years (hehe, and ensured that it can't overtake
other similar cars (standard-car-friendliness), and that
it will somehow remain useful in case of congestion  :-)  ).

Now, the way I used to look at this group is like a
collection of these car designers, with the goal of
having them agree on the car of the future (or rather, a
recommendation to the "standard car design company").

I thought that this would be impossible - if you consider
that these people haven't even agreed what metric is
better (maximum speed, better initial speed, won't fall
apart on mountain roads, ...). What's more, I thought that
agreeing on such metrics would also be impossible (I think
we even had a brief discussion in this direction), and
therefore the group could never reach this goal in the
charter:

An eventual goal is to produce a recommendation to the IETF on a
solution that would be appropriate for Internet-scale deployment.

(even this additional sentence doesn't seem to help a lot: "It is
possible that more than one solution will be recommended - this is
likely if the solutions can gracefully co-exist.")

THE ENCOURAGING FUTURE:
=======================

The way I see it now is different, thanks to Aaron - I'm not
saying that he has exactly my point of view, just that he
made me understand that there *is* a way out of the dilemma.

I say, it's unreasonable for these car designers to try and
agree on a single car, or even a single recommendation.
Instead, they need to step back and see what they learned
from what they built. For instance, if 5 out of 10 car
designers achieved higher speeds by building the motor in a
special way (this is the part where you learn that I know
absolutely *nothing* about cars  :-)    ), it might be possible
that all car designers agree that this way of building a motor
is the right thing to do.

Let me make things a little more concrete at this point:
both CUBIC and HighSpeed TCP, for instance, increase the
sender rate faster than TCP *IFF* there is little loss in
the network. Based on experience with these protocols and
perhaps others which are similar in this aspect, we could
agree that this is the right thing to do and turn it into
a general rule - a recommendation for future congestion
control mechanisms.

These are rules that we could derive by learning from
performance enhancing aspects of the various congestion
control mechanisms out there. I think that we shouldn't
even try to work towards a concrete recommendation that
says "this is what your future cc. mechanism should look
like", but really have broader rules that can serve as
a framework for future designs.

Cheers,
Michael