Re: [TERNLI] Forwarding corrupt packets

[Gorry Fairhurst <[e-mail]>]

I think it was a reasonable strawman, and is a form of cross-layer 
signalling. I suggest any L2 signalling has to demonstrate it is 
necessary, safe, etc.

Not sure the case for DCCP is much stronger, but would could think on 
this. My take is that links have to work hard to get UDP-Lite-style L2 
processing working effectively. Links that do this can get benefit (if 
desigend that way). Peeking into the header may also be reasonable for DCCP.

Your deployment note at the end on UDP-Lite is a good point. If some 
signal could help address this issue, this would be a great step towards 
  real deployment, however at the moment, I'm not yet persauded this is 
the right way to do this.

Thanks,

Gorry


Michael Welzl wrote:

> On Mon, 2006-09-04 at 13:01, Gorry Fairhurst wrote:
> 
>>A) On which link layers support this?
> 
> 
> Thanks for all the interesting details!
> 
> 
> 
>>B) On whether this extra signalling is useful?
> 
> 
> At this point, I should perhaps mention that I'm not
> making a very concrete proposal here which I try to
> defend - the way I understood it, TERNLI is still in
> its defining stage and people are just tossing ideas
> around. So I thought I'd add an idea and see what the
> reaction would be - and the reactions are surely
> interesting, thanks a lot to both of you for the
> feedback you gave so far!
> 
> 
> 
>>What I don't understand is the "essence" of the message that you need to 
>>generate to utilise this, since you seem to suggest in this thread using 
>>explicit signalling to set L2 state, rather than per-packet choices.
> 
> 
> at least in the "From transport end point to network" case, yes.
> 
> 
>> > "From transport end point to network"
>>- I think we already have this as a transport option.
>>- not sure I am convinced we need the signal.
>>- I don't understand this signal... it seems to bind a specific TSpec 
>>(IPsrc,IPdst, Transport, srcport,dstport)to a L2 identity... How do you 
>>differentiate when a new app replaces the previous one with different 
>>semantics?
> 
> 
> When I proposed this, I didn't think of the parts of
> the UDP-Lite and DCCP specs that Joe pointed me to,
> which require link layers to detect that forwarding
> corrupt packets is desired.
> 
> The "beauty" of this design notwithstanding, that signal
> is therefore already existent on a per-packet basis,
> so I would now agree that the message isn't useful anymore
> in this direction.
> 
> 
> 
>> > From network to transport end point:"Corruption Forwarding supported 
>>(CF)"
>>- Why do we need to know this at the transport layer?
>>- If your end systems (and any L4 middleboxes!) support UDP-Lite and/or 
>>DCCP with partial coverage it is FINE to use this irrespective of 
>>whether the links do anyrthing special. you don't gain, but you don't 
>>loose either.
>>
>>- Can you clarify how the extra signalling helps?
> 
> 
> In DCCP, the data checksum option is extra overhead, but it is
> useless unless you have a link which delivers known-corrupt
> data. Here I'd say that it would help.
> 
> As for UDP-Lite, a reason not to use it is (as with any
> new protocol) the fact that it might not pass through
> firewalls. Thus, my application could first use UDP =>
> extra signaling tells me to try UDP-Lite, so I do.
> 
> Theoretically, it might be preferrable to always try
> UDP-Lite first, and switch back to UDP in case of failure.
> But will application programmers do this? I imagine that
> the outlook of receiving a message which tells an application
> to use UDP-Lite might be a more convincing argument for
> application programmers to support the protocol at all.
> Then again, maybe not - I'm really just guessing here.
> 
> Cheers,
> Michael
> 
>