Re: [Spud] Putting Network-Layer Information in the Network Layer

[Mirja Kühlewind <[e-mail]>]

+1

Now this extra space is for me the place where you put a SPUD header (no matter how this header looks like). I personally was seen SPUD over UDP also as a way to make UDP extensible. So you could also add end-to-end information to SPUD e.g. timestamp information, if these information are useful for different overlaying protocols…

The little 'hack' you describe below is great to address the discover problem: How do I know the other end is SPUD enable…? - I don’t care…

Mirja
 

> Am 11.07.2015 um 00:29 schrieb Joe Touch <[e-mail]>du>:
> 
> 
> 
> On 7/10/2015 3:19 PM, Tom Herbert wrote:
>> On Fri, Jul 10, 2015 at 2:44 PM, Joe Touch <[e-mail]> wrote:
>>> +1, for somewhat different reasons, notably the problem deploying new IP
>>> options and layer separation.
>>> 
>>> This really hints that UDP isn't quite sufficient without its own
>>> options. There seems only one place to do this - using the UDP length
>>> field.
>>> 
>>> E.g., let's say you have a 1500B IP packet with a 20B IP header, leaving
>>> 1480 for UDP. But instead of saying that UDP's Length is 1280, we say
>>> it's 1400; in that case, the last 80 bytes could be used as a 'trailer
>>> option area'.
>>> 
>> You get UDP data on a UDP socket, so 1400 bytes is returned.
> 
> Sure - to the user.
> 
>> Returning
>> the extra bytes would be a simple kernel and API change (at least in
>> Linux).
> 
> You'd keep that within "UDP". If you want to get at that portion, it'd
> be like accessing a raw IP socket.
> 
>> Besides that, I imagine that HW vendors probably want the
>> options to be in the headers due to the HW limitations of packet
>> processing.
> 
> They just want a quick way to find them. ;-)
> 
>> 
>>> This is somewhat like UDP-lite, except that instead of declaring the
>>> length to indicate "checksum coverage", it would just indicate the UDP
>>> payload vs. extended header, and it would use the existing UDP protocol
>>> number (17) rather than that of UDPlite (136).
>>> 
>>> ---
>>> The reason why this mechanism can use the current UDP protocol number is
>>> that we're not changing the semantics of UDP or the length of the data
>>> delivered to the application vs. the existing UDP length field.
>>> 
>>> Because we're still assuming that the UDP checksum covers only the
>>> length indicated in the UDP header, there should be no inconsistency
>>> with "mismatching pseudoheaders" - I think. I'll check with the UDPlite
>>> crowd (unless any are already on this list - Gorry?)
>>> ---
>> 
>> IIRC there was a proposal to contort the UDP checksum to become
>> something closer to a UDP-lite checksum. The idea was to indicate this
>> mode by setting a UDP length less than 8, and inferring the actual
>> length of the UDP payload from the IP total length. Conceptually, this
>> same hack could be used to add options to UDP.
> 
> Yes, that's what I am proposing. The difference with UDP-lite is that I
> would not be returning the extra UDP header option space to the user;
> UDP-lite treats that space as "not covered by the checksum" but also
> returned to the user.
> 
> Joe
> 
>>> I'm still not convinced it's safe, though. It would not be covered by
>>> the UDP checksum. I have no idea whether existing stacks would handle it
>>> correctly (i.e., ignoring the extra bytes) vs. shortening the IP packet
>>> to make the lengths match.
>>> 
>>> NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried it
>>> to see whether it makes various OSes blow up yet...
>>> 
>>> Hmmm.
>>> 
>>> Joe
>>> 
>>> On 7/10/2015 1:45 PM, Toerless Eckert wrote:
>>>> IMHO, IP options do not get us anywhere.
>>>> 
>>>> I want a solution that works against the lowest common denominator
>>>> of APIs for applications that i have across not only platfornms,
>>>> but also application development environments. I have UDP APIs on
>>>> a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't
>>>> find IP optoins in a lot of interpreted language SDKs.
>>>> 
>>>> Even if supported by language SDK, its an OS issue whether IP optoins
>>>> are supported. I remember that some investigation for a project we did
>>>> 2? years back now resulted in us finding that at C level system APIs,
>>>> android for example was not supporting IP router alert for a UDP socket
>>>> for IPv6, even though it supported it for IPv4 (i hope i remember these
>>>> details correctly). And its just one example.
>>>> 
>>>> If all of this stuff is fine, i am totally not persuaded that IP
>>>> options are going to be accepted by network operators. There is no
>>>> way to guarantee to a network operator that packets with IP options are
>>>> NOT punted and cause performance impacts.
>>>> 
>>>> We went through this exercise with ECN, and still haven't moved ahead.
>>>> After 10 years or so. Where is the stealth data-collection facility in
>>>> eg: firefox that tries randomn ECN flows not only to see whether they
>>>> pass through, but also checking latency & jitter to validate that
>>>> these ECN packets where not punted in routers when they did pass through ?
>>>> 
>>>> I am not saying we shouldn't have a glorified plan for STUN that ALSO
>>>> includes the architecture for doing it correctly for the
>>>> 1980's Internet architecture, but please lets not make this plan A.
>>>> 
>>>> The Internet architecture has evolved on so many fronts. Can we not
>>>> learn in the network/transport layer structure too how to get the
>>>> best solutions for reality ?
>>>> 
>>>> Just saying.
>>>> 
>>>> Toerless
>>>> 
>>>> On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch wrote:
>>>>> Hi, Brian,
>>>>> 
>>>>> On 7/10/2015 3:44 AM, Brian Trammell wrote:
>>>>>> 
>>>>>>> On 09 Jul 2015, at 19:36, Joe Touch <[e-mail]> wrote:
>>>>> ...
>>>>>>> IPv4 options can be jumped over in one step using the IHL field.
>>>>>> 
>>>>>> yes, |set| = 1.
>>>>> 
>>>>> Well, it's actually also because the offset is in the default header and
>>>>> nowhere else. The number of options varies, as does the length of many
>>>>> options.
>>>>> 
>>>>>>> There's
>>>>>>> no such field for IPv6 - routers have to walk the chain of headers one
>>>>>>> by one.
>>>>>> 
>>>>>> Right. It seems to me the way out of this (which is not just a
>>>>>> problem for boxes that want to muck about in transport protocols, but
>>>>>> ones thatwant to properly process hop by hop options) would be to
>>>>>> define a new(small) set of IPv6 options headers that themselves would
>>>>>> (1) not be combinable and (2) have a fixed length, allowing the
>>>>>> next-header field to be _treated_ in constant time / with relatively
>>>>>> few gates as the IHL field.
>>>>> 
>>>>> There are several hurdles, not the least of which is that the length of
>>>>> HBH options can change in transit.
>>>>> 
>>>>> You don't really need a fixed length to solve this, or even a fixed set.
>>>>> The options can even be mutable.
>>>>> 
>>>>> What you really need is a "jump to transport" header that comes before
>>>>> all the others, and that is maintained by any device that adds, deletes,
>>>>> or changes the length of an option.
>>>>> 
>>>>> The real problem there isn't doing that; its knowing whether you've
>>>>> traversed a router that obeys those rules without dropping packets at
>>>>> routers that don't. That would kill IPv6.
>>>>> 
>>>>>> I haven't followed 6man, though I presume this approach or
>>>>>> approaches like it have been discussed there ad nauseam.
>>>>> 
>>>>> See above.
>>>>> 
>>>>>> The fixed-lengthness of these new v6 options headers would make them
>>>>>> problematic for freely extensible options, though one could use these
>>>>>> to stick common fast path options in the "fixed" point of the header,
>>>>>> and otherwise point to space elsewhere in the packet for things that
>>>>>> can happen slowly. You eat the cost of following pointers and doing
>>>>>> the more expensive deframing only if you need to in this case.
>>>>> 
>>>>> The real issue, AFIACT, is detecting the behavior of legacy devices that
>>>>> wouldn't know to follow these rules - without having them drop the
>>>>> packet because it is an unknown option (i.e., you can set "drop if
>>>>> unknown", but that would be bad; if you don't set that bit, then you
>>>>> can''t detect when changes occur easily).
>>>>> 
>>>>>>>>> I suspect you'll find that IP options are basically a non-starter except
>>>>>>>>> for research purposes.
>>>>>>>> 
>>>>>>>> For the story on the v4 side, do you know of anything newer than
>>>>>>>> Fonseca et al "IP Options are Not and Option" (tech report version at
>>>>>>>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's
>>>>>>>> ten years old -- but given where the engineering effort has gone during
>>>>>>>> that decade, I doubt strongly much has changed here.
>>>>>>> 
>>>>>>> Not much. Those old studies have been used in other WGs to drive
>>>>>>> documents (IMO, unfortunately).
>>>>>> 
>>>>>> I've been thinking about whether it would be worth the effort to do
>>>>>> an updated IP options transparency study.
>>>>> 
>>>>> The IETF has a persistent problem with extensibility. Vendors don't make
>>>>> money supporting capabilities not in current use, but that ossifies the
>>>>> protocols badly.
>>>>> 
>>>>> Joe
>>>>> 
>>>>> _______________________________________________
>>>>> Spud mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/spud