Subject: [conex] Fwd: New Version Notification for draft-briscoe-tsvwg-re-ecn-tcp-09

From: Bob Briscoe <[email-masked]>
Date: Mon, 25 Oct 2010 23:04:43 +0100

ConEx folks,

I have posted revisions of the old re-ECN drafts just to keep them 
live on the IETF servers for people referring to them. I've left them 
with their old tsvwg filenames so it's clear we have no intention to 
propose re-ECN as a solution for ConEx.

draft-briscoe-tsvwg-re-ecn-tcp-08 -> 09
draft-briscoe-tsvwg-re-ecn-tcp-motivation-01 -> 02

Bob

>From: IETF I-D Submission Tool <[email-masked]>
>To: <[email-masked]>
>CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Subject: New Version Notification for draft-briscoe-tsvwg-re-ecn-tcp-09
>Date: Mon, 25 Oct 2010 12:06:40 -0700
>
>
>A new version of I-D, draft-briscoe-tsvwg-re-ecn-tcp-09.txt has been 
>successfully submitted by Bob Briscoe and posted to the IETF repository.
>
>Filename:       draft-briscoe-tsvwg-re-ecn-tcp
>Revision:       09
>Title:          Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
>Creation_date:  2010-10-25
>WG ID:          Independent Submission
>Number_of_pages: 50
>
>Abstract:
>This document introduces a new protocol for explicit congestion
>notification (ECN), termed re-ECN, which can be deployed
>incrementally around unmodified routers.  The protocol works by
>arranging an extended ECN field in each packet so that, as it crosses
>any interface in an internetwork, it will carry a truthful prediction
>of congestion on the remainder of its path.  The purpose of this
>document is to specify the re-ECN protocol at the IP layer and to
>give guidelines on any consequent changes required to transport
>protocols.  It includes the changes required to TCP both as an
>example and as a specification.  It briefly gives examples of
>mechanisms that can use the protocol to ensure data sources respond
>correctly to congestion, but these are described more fully in a
>companion document.
> 
>
>
>
>The IETF Secretariat.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 29 Oct 2010 12:13:33 +0200

Hi Matt, Bob,

you introduce a separate signal to send 'credits' but you don't really explain 
why this is needed. Can you give some hints about this?

Is this needed for the dropper to ensure that the sender declares its 
congestion honestly or it this mostly helpful to get more accurate congestion 
information in the network? What are the security implication here?

Thx,
Mirja

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 29 Oct 2010 21:21:11 +0200

Hi

I agree with Mirja
I would say that this is probably the most complex part in ConEx, I recall that this was explained with some detail in the one of the "Re-ECN for TCP" drafts (don't remember which), I did not fully get it then so I would really welcome a thorough explanation of this.

/Ingemar

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]] 
> Sent: den 29 oktober 2010 12:14
> To: [email-masked]
> Subject: [conex] comments on draft-mathis-conex-abstract-mech-00
> 
> Hi Matt, Bob,
> 
> you introduce a separate signal to send 'credits' but you 
> don't really explain why this is needed. Can you give some 
> hints about this?
> 
> Is this needed for the dropper to ensure that the sender 
> declares its congestion honestly or it this mostly helpful to 
> get more accurate congestion information in the network? What 
> are the security implication here?
> 
> Thx,
> Mirja 
> 
>