[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Are we solving the wrong problem?



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 be
that HIP is implemented below TCP, so that it works also for UDP. I
think 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 it
must not move all the traffic the other way, or the system is unstable
and 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 change
the 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