Subject: Re: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Mar 2020 14:23:09 +0000

Hello Eric and Ben:

> > == COMMENTS ==
> >
> > Is there a reason why this document uses "Link-Layer address" while
> > the companion, draft-ietf-6lo-fragment-recovery, uses "MAC address" ?
> > This is cosmetic of course but if the concept is the same, using the
> > same wording could only improve the readability of the documents. Same
> applies for "datagram_tag"
> > vs "Datagram_Tag" ;-)
> >
> > -- Section 5 --
> > "Multiple fragments may progress in parallel" is not really correct as
> > the rather travel "simultaneously" as they follow the same path but at
> > different steps (i.e. not like using parallel links).
> >
> > -- Section 6 --
> > The "no per-fragment routing" can also be seen as an advantage as it
> > forces all fragments to be in order.
> 
> I think that still requires cooperation from all intermediate nodes, absent some
> requirement for them to clear buffers in FIFO order.

Yes, and there is no assumption that the fragments will be in order. One could say that it does not matter. 
It does a little bit in the case of the recovery since we resend in order so we have a chance that a packet still in flight is acked before it is retried.
The thing that really matters is the first fragment first.

All the best;

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:01:59 +0000

Hello Eric:

Many thanks for your review and time : )

You and Ben has similar concerns and I published 13 to try to address both. 
I compiled the proposed changes in an early publication https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-13  

Let's see below for the details:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 

> As I reviewed draft-ietf-6lo-fragment-recovery before this document, I put
> some COMMENTs in my review of draft-ietf-6lo-fragment-recovery that also
> apply to this document.
> 

Yes, the first comment applies here too:

> -- Section 4.2 and Section 7.1 --
> Should default values for the inter-frame gap be given ?

This is related to a point in Ben's review. It's really dependent on the MAC technology, PHY speed, number of retries (channel occupancy) , and application. 

Quoting myself (he he)

We never know when the next hop will send, it may be busy with a queue of other packets. So there's always a risk unless you schedule like you could with 6TiSCH. Also a TSCH technology will protect against the hidden terminal but a single channel mesh must let the fragment go farther away. So it's like the proverbial time it takes for the canon to cool down.:"Enough time".

So I cannot be more precise that: for TSCH, allow the next hop to forward; for single channel mesh, several times that because the frame must progress out of interference range.

"Enough time" can be expressed as what's needed for a packet to  " progress beyond the next hop and beyond the interference domain before the next shows up.  "
 Is that OK?

> == COMMENTS ==
> 
> Is there a reason why this document uses "Link-Layer address" while the
> companion, draft-ietf-6lo-fragment-recovery, uses "MAC address" ? This is
> cosmetic of course but if the concept is the same, using the same wording
> could only improve the readability of the documents. Same applies for
> "datagram_tag"
> vs "Datagram_Tag" ;-)

Let's go for Datagram_Tag and Link-Layer address in both docs?

> 
> -- Section 5 --
> "Multiple fragments may progress in parallel" is not really correct as the rather
> travel "simultaneously" as they follow the same path but at different steps (i.e.
> not like using parallel links).

True, made the change

> 
> -- Section 6 --
> The "no per-fragment routing" can also be seen as an advantage as it forces all
> fragments to be in order.

See my reply to you and Ben, the order is not really important in general though it plays a role in the recovery because the retries are in order.

> 
> == NITS ==
> 
> Is the case in "Link-Layer" correct? I am a non native speaker but I would have
> used "link-layer".

I have no idea : ) I'm used to uppercasing because of the SLLAO so I do it all the time.
I do not mind at all changing all. Maybe the RFC editor knows better?*Gain, many thanks Eric!

Pascal

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:22:10 +0000

Thank you Pascal for addressing my COMMENTs

__

-éric

-----Original Message-----
From: Pascal Thubert <[email-masked]>
Date: Thursday, 5 March 2020 at 17:02
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)

    Hello Eric:

    

    

    
    Quoting myself (he he)

    

    

    True, made the change

    

    Pascal