Subject: RE: (NAT) RSIP over TCP stream

From: "Iyer, Prakash" <[email-masked]>
Date: Thu, 4 Nov 1999 16:03:22 -0800

Can you be more specific. RSIP does support pre-allocation of blocks of
resources (such as ports) in macro policy mode, which probably means that
encapsulation on the client and decapsulating IP-IP (or one of the other
data channel encapsulation modes) at the RSIP server is the most that
happens in steady state. And the other assumption is that encapsulation does
not cause IP fragmentation. Is this the issue? Are there other concerns?

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Thursday, November 04, 1999 3:45 PM
To: Matt Holdrege
Cc: Iyer, Prakash; 'Mike Borella'; [email-masked]; Saint-Hilaire,
Ylian; [email-masked]
Subject: Re: (NAT) RSIP over TCP stream

Has anyone considered the implications of delay sensitive applications
over RSIP?
--
Eliot Lear
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 Nov 1999 01:20:04 -0800

Well, I think that the issue here is tunneling overhead. 
It is no secret that tunneling schemes have an
overhead issue in voice/video scenarios and the
calculations get particularly gruesome if you are
using IPSEC for security. 

For example, if you wanted to do voice over IP 
to an Intranet via an IPSEC tunnel, the tunnel 
mode packet would need to be encapsulated
in another tunnel before being sent to the RSIP gateway. 
If integrity protection were used on the RSIP
data channel, the header overhead is pretty impressive. 

For example, assuming a 64 octet packet, 20 octet
IP header, 32 octet IPSEC AH header
(corresponding to MD5 IPSEC AH) then we could
end up with a packet like:

ip - ipsec - ip - ipsec - ip - payload

with overhead of 

(20 + 32 + 20 + 32)/64 = 104/64 = 163%

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Thursday, November 04, 1999 3:45 PM
To: Matt Holdrege
Cc: Iyer, Prakash; 'Mike Borella'; [email-masked]; Saint-Hilaire,

-