Subject: RE: [Fecframe] PNAT?

From: "Mark Watson" <[email-masked]>
Date: Wed, 9 Nov 2005 16:36:03 -0500

Caitlin,

Actually, we are concerned with erasure correction, so we are exactly
concerned with recovering packets which are lost for whatever reason
(rather than 'repairing' packets which are received with errors).

There are of course many reasons why packets which pick up an error will
be discarded before reaching the end host.

...Mark

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Wednesday, November 09, 2005 1:26 PM
To: Mark Watson; [email-masked]
Subject: RE: [Fecframe] PNAT?

I'm asking a more general question.

If the UDP port is being mangled in route, then what
UDP packets will be eligible for repair? Won't any
that are damaged in transit be tossed by the PNATting
device? If the UDP datagram is already damanged they
cannot modify the header and then forward it. 

> -----Original Message-----
> From: Mark Watson [mailto:[email-masked]] 
> Sent: Wednesday, November 09, 2005 1:19 PM
> To: Caitlin Bestler; [email-masked]
> Subject: RE: [Fecframe] PNAT?
> 
> Caitlin,
> 
> The framework itself does not have any requirements with 
> respect to NATs or NAPTs - we require that the receiver knows 
> the UDP flow definitions of the flows containing source and 
> repair data and that there is a path from sender to receiver.
> 
> Specific protocols that used the framework would have to 
> address how they work through NA(P)Ts. I assume the case you 
> refer to below is where the source and repair flows are 
> identified using different UDP ports and the traffic attempts 
> to traverse a NAT from the 'outside' to the 'inside'.
> 
> In this case, just as the protocol must arrange for a 
> suitable binding to exist for the source packets, it must 
> also arrange for a suitable binding to exist for the repair 
> packets - it is the same problem for both source and repair flows.
> 
> If you are thinking of 'retrofitting' the FEC repair flow to 
> an existing source packet protocol with existing NA(P)T 
> traversal support then I think you would need to make the 
> repair packets look like part of the same flow as the source 
> packets from the NA(P)Ts point of view. This is easy, but the 
> tradeoff is that you have to place some restrictions on the 
> packet contents. You need to have somewhere in there to 
> distinguish source from repair packets i.e. you swap some 
> generality for backwards compatibility.
> 
> Regards,
> 
> Mark
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> Sent: Wednesday, November 09, 2005 12:57 PM
> To: [email-masked]
> Subject: [Fecframe] PNAT?
> 
> Does the current proposal require that all middleboxes 
> operate strictly at L3 and below? I don't see how this scheme 
> would work if there are any middleboxes that modify the UDP 
> port numbers as part of a PNAT/firewall function. If the 
> packet had an error it would get tossed at that point, and 
> there would be no chance to repair it later.
> 
> And doesn't requiring that there me no L4 aware middleboxes 
> all but require this be IPv6?
> 
> 
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/fecframe
> 
> 

_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe