Re: [multipathtcp] Number of DSS to store

["Alan Ford (alanford)" <[e-mail]>]

Hi all,

As just mentioned in the MPTCP WG, this is one issue that it would be
really good to come up with clarifications for the draft.

So, apart from the in-order delivery of mappings, are there any other
changes that we should make? What does implementation experience tell us
here?

Cheers,
Alan

On 16/07/2012 17:21, "Alan Ford (alanford)" <[e-mail]> wrote:

>All,
>
>I've been considering how to reconcile the recent discussions in the draft
>as it stands.
>
>On Page 25 we already mention something in this area, but it does not
>cover all cases we have discussed. In particular, it currently says:
>
>  Implementations MAY hold onto such unmapped data for a short while in
>  the expectation that a mapping will arrive shortly. [...]
>  If a mapping for that subflow-level sequence space does
>  not arrive within a receive window of data, that subflow SHOULD be
>  treated as broken, closed with an RST, and any unmapped data silently
>  discarded.
>
>However, I'm not sure this really works. If a mapping was sent on a
>duplicate ACK, this may not be discovered in time (by the lack of a DATA
>ACK within said window). Maybe this actually needs to be one
>2*receive_window?
>
>Given the recent feedback, it looks like we also need to add more
>constraints. For a simple requirement, how about we add:
>
>  A mapping for subflow seqno x MUST not be sent before the mappings for
>  subflow seqno 0 .. x-1 have been sent.
>
>This shouldn't affect normal operation, since in the event of lost packets
>the subflow will handle the re-ordering before it gets to MPTCP
>processing.
>
>
>Later requirements discussed included:
>
>  a) A mapping MUST appear, at latest, in the segment where is the first
>  byte it covers is.
>
>  b) If a DSS-mapping goes from x -> y in the subflow-seqno space, the
>  DSS-option MUST be on one of these segments.
>
>
>However, the latter of these prevents a duplicate ACK giving a mapping
>being used before the data; and the former prevents preemptive mappings
>entirely.
>
>I do not see we have reached a particular consensus of what restrictions
>we want to place on preemptive mappings. Can we refine anything here to
>ensure a manageable and deterministic behaviour?
>
>Regards,
>Alan
>
>On 05/07/2012 14:54, "Christoph Paasch" <[e-mail]>
>wrote:
>
>>On Thursday 05 July 2012 08:47:03 Hampel, K Georg wrote:
>>> It is not known how packet-re-segmenting middleboxes align DSS and
>>>payload.
>>> When packet-re-segmentation occurs the DSS mapping may arrive earlier
>>>at
>>> the receiver than the corresponding payload.
>>
>>How could this happen? Can you give an example with sequence-numbers,
>>where 
>>the DSS is not on one of the packets whose sequence-numbers he belongs
>>to.
>>
>>What I mean is:
>>
>>If a packet with DSS-mapping x -> y and subflow-seq-no x comes at the
>>middlebox.
>>How could the middlebox resegment this packet so that the DSS-mapping is
>>on 
>>packet with subflow-seq-no x-1 ?
>>This is a very buggy middlebox in my opinion, as it is sending a segment
>>(x-1) 
>>that has already passed by this middlebox in the past.
>>
>>
>>Christoph
>>
>>
>>> Therefore, as long as we subscribe to the assumption that
>>> packet-re-segmenting middleboxes exist, the implementation needs to
>>>support
>>> preemptive mappings.
>>
>>
>>
>>-- 
>>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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/multipathtcp
>