Subject: [tsvwg] Refs for draft-manner-tsvwg-gut-00

From: Bob Briscoe <[email-masked]>
Date: Thu, 04 Feb 2010 11:13:05 +0000

Jukka,

* draft-fairhurst-6man-tsvwg-udptt-02:
GUT could use the simpler header-only checksumming in this draft to 
minimise processing cost.

* RFC5405 S.3.1.3. UDP Tunnels (Best Current Practice)
This says that a UDP tunnel (GUT is a UDP tunnel) should implement 
its own congestion control if it knows that the protocol it 
encapsulates doesn't.

[[[BTW, For future protocols, in the Internet Capacity Sharing 
Architecture Design Team of the ICCRG, we're (v slowly at the mo) 
trying to relax the need for RFCs like 5405 by introducing an 
architecture where transports aren't solely responsible for 
congestion control - networks have responsibility too,
<http://trac.tools.ietf.org/group/irtf/trac/wiki/CapacitySharingArch>
but for now you will need to reference this BCP, I guess.
]]]

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Jukka Manner <[email-masked]>
Date: Tue, 09 Feb 2010 12:24:25 +0200

Hi Bon,

> minimise processing cost.

Sure, that looked doable.

> This says that a UDP tunnel (GUT is a UDP tunnel) should implement its
> own congestion control if it knows that the protocol it encapsulates
> doesn't.

Aarrgghh, no! Essentially GUT only adds a header and tries to maintain 
as little state as humanly possible. Adding congestion control there, 
which implies more state and a feedback loop, would then just create yet 
another monster protocol. (yet, we could run GUT with DCCP and get CC, 
so have [IP][UDP][GUT][DCCP][encapsulated protocol] :)

> Architecture Design Team of the ICCRG, we're (v slowly at the mo) trying
> to relax the need for RFCs like 5405 by introducing an architecture
> where transports aren't solely responsible for congestion control -
> networks have responsibility too,

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 9 Feb 2010 10:29:10 -0800

> its own congestion control if it knows that the protocol it  

How would a generic tunneling mechanism "know" if an inner protocol  
implements congestion control or not? You might tunnel IPsec that  
doesn't implement congestion control, but has TCP running on top of it.

- Pasi

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 9 Feb 2010 12:37:26 -0600

I think the situation is that the tunnel protocol either:

1 - knows that the inner protocol does implement some form of CC
2 - knows that the inner protocol doesn't include CC
3 - isn't sure

RFC 5405 speaks to case 2, but not so much case 3 which is where
IPsec falls.  5405 does say that IP-based inner protocols are
generally assumed to be congestion controlled by the inner source
and destination, so I think it's reasonable to default to OFF in
case 3.

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Pasi Sarolahti
>Sent: Tuesday, February 09, 2010 1:29 PM
>To: Bob Briscoe
>Cc: tsvwg IETF list; Nuutti Varis
>Subject: Re: [tsvwg] Refs for draft-manner-tsvwg-gut-00
>
>

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 9 Feb 2010 11:00:15 -0800

On Feb 9, 2010, at 10:37 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE  

> and destination, so I think it's reasonable to default to OFF in

Yep, I thought that something like this would have been the intent in  
RFC 5405. And I think a generic tunneling mechanism would fall into  
case 3 above, because it couldn't know what future protocols emerge.  
There could be a recommendation, though, that non-congestion  
controlled protocols shouldn't use GUT.

- Pasi

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Feb 2010 12:50:06 +0000

Pasi,

I only wanted to hilite to Jukka that he ought to refer to this RFC. 
I was expecting him to accompany the ref with something along the 
lines of what you guys have concluded. Thanks

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Feb 2010 12:57:14 +0000

Jukka,

At 10:24 09/02/2010, Jukka Manner wrote:
>Aarrgghh, no! Essentially GUT only adds a header and tries to 
>maintain as little state as humanly possible. Adding congestion 
>control there, which implies more state and a feedback loop, would 
>then just create yet another monster protocol. (yet, we could run 
>GUT with DCCP and get CC, so have [IP][UDP][GUT][DCCP][encapsulated 
>protocol] :)

Don't worry. I wasn't saying I believed GUT should implement cc. In 
fact, as you may know I'm trying to define a capacity sharing 
architecture that allows constraints on end-point congestion controls 
to be relaxed. But in the interim we have to work with RFC5405.

I was just saying the GUT draft will need to justify why it doesn't 
need to do cc, with ref to that RFC. If I didn't say it, someone else 
would later in the process, so we might as well sort it now.

Bob