Re: [multipathtcp] MPTCP Schedulers

[Olivier Bonaventure <[e-mail]>]

Vlad,
>>> I'm trying to tie up any loose ends in the SOCKS 6 draft. There is some
>>> functionality which lets you change the MPTCP scheduler used by the
>>> proxy. The available schedulers are basically the ones available in the
>>> Linux kernel implementation.
>>> (https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-05#page-20)
>>>
>>> Do you think it would be worthwhile to standardize the MPTCP schedulers?
>>> I think an informational or best practice RFC would be useful.
>> I think that this would make sense, but we could also encode the
>> requested MPTCP scheduler inside an MPTCP option instead of putting it
>> in an application level message as you propose in your draft. The
>> advantage of using MPTCP options is that the same solution would work
>> for any application.
>>
>>
>> Olivier
> 
> Hi,
> 
> I agree that it is worthwhile doing it at L4. As far as SOCKS is 
> concerned, this would also open the door for the client controlling the 
> scheduler used not only by the proxy, but also by the remote host.

Agreed

> I'd argue that being able to do it at the application layer is also 
> useful, even if your proposed option gets standardized. The scheduler 
> option will not fit inside a SYN + MP_CAPABLE + TFO (along with SACK, 
> TS, MSS and Wscale) and you'll have to send it 1 RTT later. (In fact, 
> not even the TFO option will fit if the cookie is large.) OTOH, there is 
> on such pressure oh the SOCKS option space; you've got 16K to play with.

The scheduler is not that important in the first rtt since you only have 
one subflow at that time anyway. I agree that SOCKS has a larger space 
to encode options, but after the SOCKS exchange you cannot send SOCKS 
data anymore. This means that with a SOCKS solution you can set the 
scheduler for the entire connection, but never change it during the 
connection. An MPTCP option could be used at the beginning of a 
connection but also at any time during the connection lifetime


Olivier