Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00

[Olivier Bonaventure <[e-mail]>]

Hello,


> >
> > From my perspective, I think following are two different requirements:
> >
> > 1. Making all the traffic towards S2 (for this case, MP_PRIO may be enough)
> >
> > 2. Making traffic only from <IP_C1, IP_S1> to the destination IP_S2, which means diverting traffic that should be scheduled to <IP_C1, IP_S1> to one subflow belonging to the target network interface (it is "on-demand scheduling", for this case, MP_PRIO is not enough)
>
> What is the use-case for such a scheme?

Understanding the requirements from the applications would really help
in this discussion. This could also serve as input for Multipath QUIC
where the middlebox problems that are mentioned in the draft do not
exist.

> I don't see how a multipath scheduler could assign the traffic that "would"
> have been sent to <C1,S1> to a different subflow. Because for that he would
> need to know what *would* have been sent on <C1,S1> which he can only know
> once he actually sends traffic on that subflow as that will be driving the
> congestion-window which will allow to send more (or less) traffic on <C1,S1>.

Another point that needs to be taken into account is that when client
moves, the network conditions change dynamically and the server view
might differ from the wireless conditions on the client. In this case,
it is difficult for the server to precisely decide where it wants to
receive data. See http://multipath-tcp.org/multimob/

Olivier

-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>