Hi Brian, El 06/03/2008, a las 1:34, Brian E Carpenter escribió:
On 2008-03-06 04:58, Mark Handley wrote:On Wed, Mar 5, 2008 at 3:42 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:Hi Pekka, El 05/03/2008, a las 6:39, Pekka Nikander escribió: ...The biggest differences between your thinking and HIP seems to bethat HIP is implemented below TCP, so that it works also for UDP. Ithink it matches better with the IP semantics, as a single IP address is (today) typically associated with a number of co-located TCP and UDP end-points. Then there is also work specific to TCP, e.g Christian Huitema's eTCP (or whatever it was called). I'm glad to see that more people come to the roughly same conclusions, independently. :-)right, but i think that what is missing in all these proposals is to understand the interaction with congestion control, which may be critical if they get deployed.Absolutely. The stable load-balancing properties come out of using multiple links simultaneously in such a way that congestion on one path causes more bytes to be sent the other way. But crucially itmust not move all the traffic the other way, or the system is unstableand can oscillate backwards and forwards between the multiple paths.This is the reason why I think you can solve the problem at L4 without changing the apps (or at the application layer, but only if you changethe apps), but I don't think you get the same properties if you solve the problem below layer 4.You certainly won't; but layer 4 already has to deal with unannounced changes in layer 3 today, doesn't it?
right, but i think the point is that it seems clear that layer 4 knows more about the path status than layer 3, simply because is closer to the app. So, TCP knows about whether the path is congested or not, and if it working in a much more accurate way than layer 3.
So, from my perspective, i think that each layer should perform the corresponding role. So i agree with you that the right place to select addresses (and to make the id locator split) is at layer 3, but i think that the best place to figure out when a different path is needed (either to divert the whole flow or to spill additional bytes that don't seem to fit in the current path) is at the tcp layer. The results seems to imply that if you do this, you can route around congestion and improve the overall utilization of the netowrk
One question is whether a hypothetical new pattern of layer 3 behaviour would require another round of layer 4 algorithm R&D. I have difficulty seeing how we can generically solve the problems before us at layer 4, given that layer 4 is *not* the waist of the hourglass, despite the arguments Jonathan makes in draft-rosenberg-internet-waist-hourglass-00.txt.
i agree with you here.For UDP, the problem will need to be solved below, since it doesn't seem to provide much benefit doing it at the udp layer (the other option is doing it above UDP, but people are already doing that) But for TCP, which is basically the congestion control mechanism that we have available, it seems that a much tighter realtion between id/ loc and tcp woudl indeed would be beneficial
Regards, marcelo
Making layer 4 aware of layer 3 behaviour, on the other hand, seems very desirable to me. (To give a caricatural example, it would be absurd if every time SCTP changed addresses, a layer 3 man-and-encap scheme mapped them back to the same locators.) Brian
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg