Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

>
>
> On 4/4/2016 12:49 PM, gorry@erg.abdn.ac.uk wrote:
> ...
>>>> No. It's true that UDP needs to know this, but this info needs to
>>>> arrive
>>>> at the App, either from a primitive that returns the size or from a
>>>> failed
>>>> send call when probing for a maximum datagram size. The app also may
>>>> need
>>>> to control DF if it wants to do path probing of PMTU, whereas in TCP
>>>> this
>>>> is handed within the transport protocol..
>>>
>>> Ahh - I see this now. However, IMO, that ought to be something it gets
>>> from the IP layer, not from UDP. UDP has an MSS that's defined by the
>>> protocol itself which is not all that useful to indicate to the app.
>>>
>> I see what you are saying for reading the MTU less headers, but whatever
>> the method, the APP needs to work out what to do with this. For setting
>> DF
>> this is not necessarily an IP setting for all packets, it can be a per
>> UDP
>> datagram choice.
>
> Sure, but again that argues for a transparent supplement to the UDP API,
> not for a UDP-specific API.
>
>>>>> For ECN, UDP ought to be ignorant - as should its API. The only
>>>>> question
>>>>> is whether the UDP API should have a "pass through" for signals from
>>>>> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of
>>>>> the
>>>>> UDP API; they're part of the OS endpoint API to these other
>>>>> protocols.
>>>>>
>>>> I don't understand what you are saying about an "OS endpoint API to
>>>> IP".
>>>> To me the API has to signal per-datagram on send whether ECT(0) or
>>>> ECT(1)
>>>> or neither is to be set, the receive API needs to see the received ECN
>>>> field for each datagram.
>>>>
>>>> Do you see a different way to do this?
>>>
>>> Here's the issue - when a message arrives, right now we think of it
>>> being "from UDP" as part of the UDP API. However, there are no ECN
>>> markings in UDP. It makes sense to forward the IP source/dest in the
>>> UDP
>>> API because that part of the IP header is defined as part of UDP (as
>>> the
>>> pseudoheader). However, it makes no sense to have that information
>>> available as part of what UDP passes to the app per se.
>>>
>>> So maybe each UDP message is allowed to forward a single opaque (to
>>> UDP)
>>> structure that contains information from any of its underlying layers
>>> (i.e., a pass-through signal mechanism). But I would consider that not
>>> really integral to the API of UDP.
>>>
>>> I do agree this needs to be per message, not per endpoint.
>>>
>> That sounds a lot like you are thinking about a concrete API.
>
> Way more abstract. The issue is that these features are not inherent in
> UDP - they are inherent in the IP over which UDP runs (and depend on
> that IP version).
>
>> And I agree,
>> to implement this, you can do exactly that and provide additional data
>> per
>> datagram buffer to communicate the DSCP, ECN, TTL ...
>
> My point is that - at the abstract level - UDP should not have an API
> that talks about DSCP, ECN, or TTL - that ought to be something opaque
> that UDP hands down underneath.
>
And does this particular list of things vary between IPv4 or IPv6? - I
suggest not really, apart from different naming of the TTL to HOP_COUNT?

> We shouldn't need to update the UDP API whenever IP or other layers
> change.
>
That's a good goal.

> Joe
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
Gorry