Subject: Re: [rrg] ILNP and MPTCP [was multi-homed site issues]

From: [email-masked]
Date: Thu, 12 Aug 2010 04:55:46 EDT

In einer eMail vom 11.08.2010 23:32:55 Westeuropäische Sommerzeit schreibt  
[email-masked]:

On  08/10/2010 02:31 EDT, Tony Li wrote:
> I'd recommend that we also  consider locator selection as another
> degree of freedom.  I agree  with Joel that flow control belongs to
> the transport layer, and that  path selection is part of the network
> layer.
> 
> Is  locator selection a transport function?  It would seem that  having
> it be a unilaterally network layer function is over  constraining the
> architecture.  Yet, transport cannot perform  intelligent locator
> selection without network layer input.

The  problem is that the layer-to-layer API is constrained, i.e. there
almost  isn't any!  It's like in many protocols: you want the other end
(of a  protocol, an API, any communication) to do something, but you have
no way  of telling him what you want.  However, you know that if you
tweak the  information he gets that he will probably do what you want, so
you overload  an existing mechanism.  We've done it for years with BGP
for example  e.g. the way AS paths are used.
Scott, do you hereby refer to extending the AS path length by repeated  
identical entries?

So yes I agree completely that a higher layer shouldn't be  communicating
its path wishes using src/dst pairs but it has no other  globally
implemented mechanism ... and I don't think we're going to get one  for
years. 
I read some regrets between the lines. Prior getting some other globally  
implemented mechanism it requires the will to come up with such one in the 
first  place. I showed to Robert Raszuk that it can be done. 
Now that there are LSP and ILNP on their ways - neither of them tries to  
make the network layer smarter than it currently is -   I wonder  what the 
RRG is going after.  
 
Heiner

One of  the points of MIF is to get L3 and below to be more
predictable in their  behavior, which will make L4's problem easier and
lessen the need to do  anything else.

On 08/10/2010 17:25 EDT, Brian E Carpenter  wrote:
> I can't speak for MPTCP, but is seems to me that MPTCP is based  on the
> assumption that it *can* perform intelligent locator selection  based on
> feedback from transport layer ACKs (or their absence). That's  if your
> definition of intelligence is 'get the most out of the network  layer
> without caring about path selection.'

It treats the  network layer as a black box: if it gives L3 input X
(source and  destination), a particular outcome happens and it does it
more, or less,  depending on whether it likes that outcome.

On 08/10/2010 17:37 EDT,  Tony Li wrote:
> At least as I understood it, MPTCP can consider the  full cross
> product of locators and make use of dynamic feedback for  adjustments.
> The question I'm raising is whether that's  sufficient.
> 
> For example, if transport got feedback about path  selection and
> congestion from the network layer, then perhaps  transport could be
> more intelligent.  For example, if multiple  locator pairs all result
> in paths that coincide on a particular  congested link, then the
> benefits of multi-pathing could be extremely  limited.
> 
> More information is available, if transport is  willing to increase
> its interaction with the network layer.

All  true.

Scott
_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Thu, 12 Aug 2010 07:14:38 -0400

>From the conex- mailing list:

further arguments against handling congestions by the hosts.

I would assume that it is in the interest of some particular ISP that its routers can cope with congestion and that they would like solutions which do not depend on wether the majority of host will be equipped with MPTCP and similar concepts. This means they would like to depend on their own. 

I think it is more than obvious where to put congestion handling intelligence. 

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Mikael Abrahamsson <[email-masked]>
An: [email-masked]
Verschickt: Do., 12. Aug. 2010, 12:27
Thema: [conex] comments on draft-conex-mechanism-00.txt

Hi. 
 
Just subscribed to the list (missed the start of this WG), sorry, can't reply to another thread because I don't have the original email. 
 
So, I've started reading draft-conex-mechanism-00.txt. I object to the writing: 
 
"For an operator facing congestion caused 
  by other operators' networks, building out its own capacity is 
  unlikely to solve the congestion problem." 
 
If traffic isn't DDoS or caused my malware, it's traffic the customer wanted. The traffic isn't caused by "other operators' networks", it's caused by customer interaction with customers on other ISPs networks, thus something the customer wants to do. The above writing perhaps has place in a text sent so the regulator by a an entity who wants to justify its actions and avoid regulation or repercussions, but I don't think it is appropriate in an IETF document. 
 
Oh well, over to the more technical part: 
 
7. Use cases. I don't agree on the three approcahes. Point 1 and 3 means a router has to handle flows, this doesn't scale. Point 2 involves the "router" being congested. Perhaps what's meant is that a link connected to the router is congested egress (because that's where the queue will be)? 
 
As I've said before, we're going more and more to simple cheap devices with small buffers and forwarding tables that are really quick (TCAM or alike). These devices are not flow aware and they don't really do RED either (it's pointless considering their small buffers). It's an important consideration for this wg how this should be handled. I don't see any discussion about it... 
 
7.1. Here it's said that flow-aware equipment is expensive, that's good. It's important to remember. Again, there is talk about "congested routers" which I think is the wrong term. 
 
8. Here is a good point about congestion not being a secret. The problem is that the IP stack knows about it, but the user does not (apart from deducing this from what how the application is behaving ("slow")). As some has seen from my postings on other IETG lists, I think there should be user insight into performance (metrics how the IP stack is behaving so this can be exposed to the user). Could this be part of the work done in this WG, actually exposing the CONEX performance data to the user? I think this is an important point. 
 
I don't really object to the work being done, it's just that since ECN hasn't caught on in real life (it's in most end user OSes nowadays, I don't know many network devices which are ECN aware) I don't really see how the new propsals are actually going to be deployed? Are the hardware guys involved in the discussions so we know how hard things are to implement? 
 
-- Mikael Abrahamsson email: [email-masked]

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Aug 2010 08:17:43 -0400

On 08/12/2010 07:14 EDT, [email-masked] wrote:
> I would assume that it is in the interest of some particular ISP that
> its routers can cope with congestion and that they would like solutions
> which do not depend on wether the majority of host will be equipped with
> MPTCP and similar concepts. This means they would like to depend on
> their own. 
> 

This is about congestion control on a particular path.  The multipath
approaches (MPTCP, SCTP CMT) attempt to respond to congestion across
multiple paths.  If the network is running conex on individual paths,
the trick is getting the algorithms right for balancing traffic across
multiple paths in that environment.  The end-to-end principle does
apply, but sometimes it's good to do things in the network.

Scott