Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS)

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Warren,

We will post the text by tomorrow.

Regards
Sri

On 8/15/17, 10:46 AM, "Warren Kumari" <[e-mail]> wrote:

>This document is on Thursday's telechat - I have not seen proposed
>text to address my concerns, and so I'm continuing to hold my DISCUSS
>position.
>
>W
>
>On Wed, Aug 2, 2017 at 5:18 PM,  <[e-mail]> wrote:
>> Hello
>>
>> Please see inline
>>
>> Pierrick
>>
>>
>>
>> Sent from my cell phone, mind the typos.
>>
>> -------- Message d'origine --------
>> De : Warren Kumari <[e-mail]>
>> Date : 02/08/2017 22:23 (GMT+01:00)
>> À : The IESG <[e-mail]>
>> Cc : [e-mail], Jouni Korhonen
>> <[e-mail]>, [e-mail], [e-mail],
>> [e-mail]
>> Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04:
>>(with
>> DISCUSS)
>>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-dmm-mag-multihoming-04: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to 
>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Section 3.2.  Traffic distribution schemes
>> "Per-packet management: the LMA and the MAG distribute packets,
>>belonging to
>> a
>> same IP flow, over more than one bindings (i.e. more than one WAN
>> interface)."
>> This immediately made my out-of-order-packets antenna pop up, so I read
>>the
>> section looking for mitigations. The very next sentence reads: "Packet
>> distribution can be done either at the transport level, e.g. using
>>MPTCP or
>> at
>> When operating at the IP packet level, different packets distribution
>> algorithms are possible. " -- the fact that this sentence is a:
>>malformed
>> and
>> b: hand-wavy did nothing to allay my concerns, so I read further: "The
>> distribution algorithm is left to implementer but whatever the
>>algorithm is,
>> packets distribution likely introduces packet latency and out-of-order
>> delivery.  LMA and MAG shall thus be able to make reordering before
>>packets
>> delivery." - I agree with the first sentence (although it is poorly
>>worded),
>> but the second sentence doesn't follow from the first; "shall thus be
>>able
>> to"
>> implies that the prior text somehow provides a solution, not points out
>>a
>> problem (the sentence is also malformed)-- I think you mean something
>>like
>> "The
>> LMA and MAG thus need to be able reorder packets to their original order
>> before
>> delivery."
>>
>> This then continues with "Sequence number can be can be used for that
>> purpose,
>> for example using GRE with sequence number option [RFC5845]." - I think
>>that
>> the actual reference should be RFC2890, but regardless of this, I don't
>> think
>> that what you are proposing works - "The Sequence Number field is used
>>to
>> maintain sequence of packets **within** the GRE Tunnel." (from RFC2890,
>> emphasis added). This means that sequence numbers are local to the
>>tunnel,
>> and
>> (as I understand it) your solution involves diverse tunnels. Further,
>> Section
>> 2.2. Sequence Number says: "The receiver may perform a small amount of
>> buffering in an attempt to recover the original sequence of transmitted
>> packets. In this case, the packet may be placed in a buffer sorted by
>> sequence
>> number." - if you are proposing using a single sequence number space for
>> multiple tunnels, you will end up with sequence number space gabs, and
>>lots
>> of
>> buffering, etc. The section ends with: "However, more detailed
>> considerations
>> on reordering  and IP packet distribution scheme (e.g. definition of
>>packets
>> distribution algorithm) are out the scope of this document." - I think
>>that,
>> unless the prior paragraph is significantly reworked, it should not try
>>and
>> suggest any mitigations.
>>
>>>> ok
>>
>> The whole idea of striping packets of a flow across (notably) different
>> transports seems like a really bad idea to me -- is it actually needed?
>>
>>>> some use-cases implement per-packet distribution. However this
>>>>document
>>>> does not aim to make recommendation on the way to distribute packets
>>
>>
>> 
>>_________________________________________________________________________
>>________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>>been
>> modified, changed or falsified.
>> Thank you.
>
>
>
>-- 
>I don't think the execution is relevant when it was obviously a bad
>idea in the first place.
>This is like putting rabid weasels in your pants, and later expressing
>regret at having chosen those particular rabid weasels and that pair
>of pants.
>   ---maf