Re: [multipathtcp] Number of DSS to store

A DSS option may not be sent with corresponding data if there isn't  enough tcp option space available such as due to the presence of SACK blocks. 

On Jul 31, 2012, at 5:37 PM, "Alan Ford (alanford)" <alanford@cisco.com> wrote:

> 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)" <alanford@cisco.com> 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" <christoph.paasch@uclouvain.be>
>> 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
>>> multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp