[Iccrg] Re: #1/2 draft-mayutan-ledbat-congestionarchitecture-00.txt

[[e-mail] (Bob Briscoe)]

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/9595057b/attachment.html
>From [e-mail]  Sun Mar 21 20:13:41 2010
From: [e-mail] (Bob Briscoe)
Date: Sun Mar 21 20:23:17 2010
Subject: [Iccrg] Re: #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[e-mail] m>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

Mayutan,

At 15:37 21/03/2010, Mayutan A. wrote:
>Hi Bob,
>
>Thanks once again for your feedback. See inline.
>
>On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe 
><<mailto:[e-mail]>[e-mail]> wrote:
>Mayutan, Xiaoming, KK,
>
>Mail #2 of 2: Thoughts on the decomposition itself
>
>Bandwidth-estimation module
>---------------------------
>I propose it's better to think of this as a 
>Window-overshoot-mitigation module.
>
>i) Bandwidth is the wrong concept. A cc is looking for how much data 
>it can risk setting off in flight when it's got insufficient 
>information to determine a precise answer. That's a window concept 
>[unit: byte], not a bandwidth concept [unit: b/s]. Take QS. The 
>router thinks in terms of spare b/s. But the transport has to 
>multiply that by RTT to get the initial window it should use.
>
>
>Currently, what I have in mind is the estimation of actual bandwidth 
>to assist the flow-control module and leave it to the flow-control 
>module to convert this to a relevant window size. In theory, this 
>module could indicate window size too. Thanks for the alternate name 
>suggestion.

I'm not concerned about just the name. The semantics of window is 
what I think you need here, not bandwidth. This is important to get right.

[A similar example: Stas Shalunov pointed out to me once (I think 
repeating someone else) that if MTU had been defined in units of 
time, not bytes, packets would have grown naturally as link 
technology increased and data networking would have evolved very 
differently. Effectively the MTU is the liaison concept between IETF 
and IEEE. Similarly, the interface to your top module is important to 
get in the right units.]


>ii) It's not so much about estimating the right window. It's more 
>about ensuring the window is not too wrong, while trying to 
>otherwise be as greedy as possible.
>
>
>By estimation, I meant the above. Thanks for phrasing it well. I 
>should probably use a different word here or the name suggested by you.

Cheers



Bob


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/8880de75/attachment.html
>From [e-mail]  Mon Mar 22 20:02:05 2010
From: [e-mail] (Eddy,
	Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Mon Mar 22 20:14:25 2010
Subject: [Iccrg] RE: IETF 77 agenda
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

Note that the session originally planned for Thursday was swapped to a Wednesday morning timeslot.

The ICCRG meetings are now scheduled for:

Tuesday morning 9:00 - 11:30 in Palos Verdes
and
Wednesday morning 9:00 - 11:30 in California D

For remote participatoin, you can find links to the streaming audio and presentation material from here:
http://tools.ietf.org/agenda/77
and search for "iccrg".



________________________________________
From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Sent: Monday, March 08, 2010 12:28 PM
To: [e-mail]
Subject: IETF 77 agenda

I've posted a draft agenda for the ICCRG sessions at IETF 77 here:
http://www.ietf.org/proceedings/10mar/agenda/iccrg.txt

Despite having 2 sessions, it's still a packed agenda, so I'm
planning to stay close to times allotted.  Please keep this in
mind when preparing presentations.

The mailing list has been relatively quiet for some time, so
please feel free to post background or other discussion
material which might help us to save time in presentations or
encourage discussion.

If there are revisions to timeslots, titles, etc. needed, just
let Michael and I know.

See you in Anaheim.

--
Wes Eddy
MTI Systems
>From [e-mail]  Tue Mar 23 16:16:25 2010
From: [e-mail] (Bob Briscoe)
Date: Tue Mar 23 16:25:49 2010
Subject: [Iccrg] Report re Wes's talk right now: ICCRG related IETF stuff
Message-ID: <[e-mail]>

Folks,

In 2008, we had a workshop with a bunch of IETF & IRTF people at 
Sholss Dagstuhl in Germany on interelation between Transport & 
Network layer that identified interactions between things going on at 
each layer. It particularly focused on the interaction between 
locator-ID split developments and congestion control. But also some 
of the other things Wes just mentioned.

Here's the report:

Dagstuhl Perspectives Workshop on End-to-End Protocols for the Future 
Internet, Jari Arkko (Ericsson) Bob Briscoe (BT), Lars Eggert 
(Nokia), Anja Feldmann (TU Berlin & DT) and Mark Handley (UCL), ACM 
Computer Communications Review (Editorial Zone) 39(2) 42--46 (Apr 2009).
<http://www.bobbriscoe.net/pubs.html#dagstuhl-fi>


Bob



________________________________________________________________
Bob Briscoe,                                BT Innovate & Design