Re: [manet] next version of pause extension

[Lou Berger <[e-mail]>]

Rick,

On 11/08/2017 09:34 AM, Rick Taylor wrote:
> Lou, Henning,
> 
> Top posting to summarize...
> 
> I just missed the submission deadline for LIDs, but I have a version-02 
> ready to go when the window reopens on the 11th.
> 
> Meanwhile, I think the direction Lou is going with the QueueIds is
> pretty close to what we were discussing about LinkIds - orthogonal in
> meaning, but similar in approach.
> 
> I'm with Lou on not holding up Pause while waiting for LIDs, as they
> are unrelated.
> 
> However, I do worry that the Pause extension and the DiffServ CW
> extension seem to do very much the same thing, in subtly different
> ways:  Both announce the queues in use for the session and assign Ids
> and some kind of flow marking information (+1), and both then use those
> QueueIds to identify queues for operations (again +1).
> 

I really view Pause and Credit as having different use cases.  The first
is fairly simple to implement but is likely to be inefficient, i.e.,
result in periods of time when the link is idle.  The second is far more
powerful and complex to implement, but is likely to be more efficient
*and* allow a smart router to make more sophisticated decisions based on
window sizes.

> However, I know various of us involved in DLEP over the years have all
> known that 'flows' and 'queues' need to be addressed at some point, and
> I wonder if this is the moment.  Is it time to pull the 'Queue/Flow
> Identifier' text out of both extensions and consolidate it into a
> single draft, which CW and Pause (and others) can then reference?

The defined mechanisms in the Credit draft are currently structured
(intentionally) to allow of future reuse.  In particular the same credit
control can 100% be applied *without modification* to different forms of
traffic identification and classification, e.g. 802.1 PCPs.

I thought about breaking credit window control and traffic
classification into their own documents, but then decided that future TC
definitions/extensions could just reference the DIs defined in this
document - so there was no substantive value in doing this, but it
certainly is a valid options.  Of course, we can break into two if the
WG prefers.

Thanks,
Lou
>  We
> can then all have a good argument about packing DSCP code points into
> 'sub-tlvs' once for one document, and follow it up with mechanism
> extensions for different use-cases of different types of 'flow'.
> 
> Thoughts?
> 
> Rick
> 
> On Wed, 2017-11-08 at 09:01 -0500, Lou Berger wrote:
>> Henning,
>>
>> see below.
>>
>> On 11/08/2017 02:23 AM, Henning Rogge wrote:
>>> Rick, Stan and me had also a discussion about this when talking
>>> about
>>> the "link ID" extension...
>>
>> I followed the thread (I think) -- I was hoping we'd get some good
>> time
>> in Singapore to discuss this - will you (and Rick+ Stan) be there?
>>
>>>
>>> I proposed the idea that we use "link IDs" to define multiple
>>> "versions" of a connection to the same target MAC address. This
>>> would
>>> also mean we could easily add a "this needs VLAN TOS x" or "this
>>> needs
>>> DSCP y" flag to a neighbor, which means we don't need to introduce
>>> "sub-TLVs".
>>
>> I'm torn, the lid approach means a lot of added messaging to
>> essentially
>> provide queue index semantics - but I also like the generic concepts
>> of
>> LIDS (although I personally think LID length should be fixed per
>> session, not per spec.)
>>
>> Given that lids are so immature, I don't think we should hold up
>> pause.
>> Let's get it done and out there, and *if* we come up with something
>> better in a year or two we can deprecate pause.
>>
>> Lou
>>
>>>
>>> Henning Rogge
>>>
>>> On Mon, Oct 23, 2017 at 3:15 PM, Lou Berger <[e-mail]>
>>> wrote:
>>>> Rick (all),
>>>>
>>>> When we last talked (ietf99, see
>>>> http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-manet). I
>>>> think we
>>>> agreed that draft-ietf-manet-dlep-pause-extension-01 captured
>>>> your
>>>> current thinking on "containers".  Are you still happy with the
>>>> draft,
>>>> or do you think there is some change needed?  If the latter,
>>>> obviously
>>>> let us know what change you'd like to see.
>>>>
>>>> Thanks,
>>>>
>>>> Lou
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>