Re: [TERNLI] Forwarding corrupt packets

[Michael Welzl <[e-mail]>]

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