Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

[Michael Welzl <[e-mail]>]

Hi,

Thanks a lot for all your comments (plus the nits we authors of the other -usage draft received offline).

I’ll try to address them all - but there are a two technical questions in this email that made me stop, so I’ll cut all the editorial stuff away and discuss them here - in line below:


> - Why do this??? - Isn't it better to set flow labels per interface or for the whole stack, how can any specific transport or application pick unique labels?
> TEXT:
> >   o  Specify IPv6 flow label field
> >      Protocols: SCTP
> 
> (i.e., Is this automatable by the host and a host wide
> configuration?)

Somehow the question seems irrelevant in the context of this draft, which is a list of transport features of protocols. These features are defined in the RFCs spec’ing the protocols - for SCTP, this is defined, and that’s why it’s here.

We can discuss this for the proposed services that a system should offer, which we try to write up in the minset draft:
I do think that an application should be allowed to assign a label to a TAPS flow (as we call them), which could then map to this function. I mean, isn’t a flow label supposed to identify a transport flow? Then a system-wide configuration wouldn't seem right to me.


> -------------------
> Get Interface MTU is missing from pass 2 and 3:
> 
> ADD to pass 2:
> 
> 	GET_INTERFACE_MTU.UDP:
> 		Pass 1 primitive: GET_INTERFACE_MTU
> 		Returns: Maximum datagram size (bytes)

But this doesn’t exist!  It’s strictly an IP function and I couldn’t find it described for UDP anywhere. I think we agreed on how a TAPS system should handle this, and this is reflected in
https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1
… which may require a system to implement new local functionality, maybe based on this MTU function - but to my understanding it’s just not something that UDP offers.


Cheers,
Michael