Re: [multipathtcp] draft terminology: MPTCP control block variable SND.NXT

Hi Christoph, Nigel,

In my understanding, in TCP, seqno before SND.NXT is already sent to
the network, while in case of MPTCP, this is not always correct. So,
in a sense, the meaning of SND.NXT might be slightly different,
although I'm not very sure if this is a problem.

Thanks,
--
Yoshifumi

On Mon, Nov 12, 2012 at 1:14 AM, Christoph Paasch
<christoph.paasch@uclouvain.be> wrote:
> Hi Nigel,
>
> On Monday 12 November 2012 17:53:37 Nigel Williams wrote:
>>  From the draft [1] v12, p59, Section B.1.2 (variables in the MPTCP
>> control block):
>> "SND.NXT (64 bits):  This is the Data Sequence Number of the next byte
>> to be sent.  SND.NXT is used to determine the value of the DSN in the
>> DSS option."
>>
>> This terminology is borrowed from regular single flow TCP, but it's
>> meaning does not seem to us to be the same in the MPTCP context. When a
>> subflow asks the scheduler for new data to send, the scheduler allocates
>> a chunk of the TX socket buffer to the subflow, tells the subflow the
>> starting DS value for the chunk and the length of the chunk. The subflow
>> then proceeds to send a DS map for the chunk and all the associated data
>> before calling back up to the scheduler to get a new chunk allocated.
>>
>> Each subflow's internal concept of snd.nxt makes sense as in the regular
>> single flow TCP case, but at the DS level, packets leave the machine
>> with DS-level sequence numbers that jump all over the place (when using
>> mappings > 1-MSS on multiple subflows).
>
> This depends on the scheduler, and I don't see why mappings > 1-MSS affects
> this.
>
> Is the data leaving the sender out-of-order on the data-sequence number space
> in your implementation?
>
> In our implementation, even if the mapping would be > 1-MSS, the SND.NXT is
> simply increasing as new data is pushed out on the network.
> I believe that. sending the data in-order on the DS-level allows an easier
> handling of the meta-level retransmission timer.
>
>
> Cheers,
> Christoph
>
>> The interesting variable at the
>> DS level is really the largest DS value mapped to a subflow i.e. the
>> right most edge of the TX socket buffer which designates the boundary
>> between bytes which have been mapped into subflows and bytes which have
>> not. This is not analogous to an individual TCP flow's SND.NXT though,
>> hence the point of discussion.
>>
>> cheers,
>> nigel
>>
>>
>> [1] http://www.ietf.org/id/draft-ietf-mptcp-multiaddressed-12.txt
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
> --
> IP Networking Lab --- http://inl.info.ucl.ac.be
> MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
> Université Catholique de Louvain
> --
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp