Re: [conex] Accounting of ConEx signals

[Bob Briscoe <[e-mail]>]

Mirja,

If pure acks were ECN-capable, it would be just 
as likely that they would get an ECN mark as any 
data packet. However, RFC3168 says pure ACKS must 
be sent as Not-ECT. We should keep to this in 
ConEx unless something better has been done that 
I'm not aware of - ConEx isn't chartered to work on loss/marking of pure acks.

There is RFC5690, which is informational (rather than experimental):
"Adding Acknowledgement Congestion Control to TCP"

The relevant section in the re-ECN spec about 
pure acks, and byte vs packet ConEx signalling is 
here, which covers nearly everything in the present thread:
<http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09#section-6.1.5>


This leaves the outstanding question of which 
ConEx doc should write about this stuff.
* abstract-mech ought to cover things like which packet headers to include.
* conex-tcp-modifications obviously ought to talk about TCP-specifics
* that leaves where to put design principles 
applicable to all transports. 2 options:
   a) abstract-mech?
   b) a section in conex-tcp-modifications 'guidelines for other transports'?

I prefer a) but we don't really want extremely detailed stuff in abstract-mech.


Bob

At 12:42 11/10/2011, Mirja Kuehlewind wrote:
>Hi Bob,
>
>thanks for this separate answer on the second 
>question but actually your first
>answer help me already. When I was reading your mail, I've just though, that
>we can at the endsystem just count the TCP payload. Under the assumption that
>the endsystem is mostly sending equally sized packets, there will be
>automatically as many header with ConEx marks as there have been causing the
>original congestion. If the sender is doing some wired things, like sending
>smaller retransmit packets, the sender knows about it and can take exactly
>this knowledge into account.
>
>I talked to Richard about this and he was bring 
>up the case, when there is ACK
>congestion (control packets without payload get marked). Not sure what to do
>with this case. If an ACK get lost, we actually don't really know. We could
>assume that the receiver should ack as least every second packet but we never
>know what the receiver did. I believe usually control packets without payload
>are as well ECN-capable. So with ECN we  would have a congestion signal. But
>is this a common case that pure ACKs get ECN markings?
>
>Mirja
>
>
>On Monday 10 October 2011 18:46:06 Bob Briscoe wrote:
> > Mirja,
> >
> > The thread largely overlooked your second question, which is also a good
> > one.
> >
> > We haven't got any text anywhere that talks about this.
> >
> > IMO the size should include the network layer header, but not link layer.
> >
> > Reason: ConEx is targeted at the IP layer because
> > it is the interoperability layer across networks.
> > When the bytes of a packet cause congestion
> > (setting aside the discussion about packet
> > processing congestion), the IP header is always
> > there, so it is part of the size that always needs to be counted.
> >
> > So, when we add ConEx to TCP, byte-for-byte
> > balance should strictly take account of IP
> > headers. But as you rightly point out, TCP often
> > doesn't know how many IP headers are involved (or
> > how many TCP headers were involved the last time
> > round the loop). So again, we can only say that
> > the practical approach when coding TCP is to make
> > assumptions about IP and TCP headers (e.g. assume
> > there will always be about the same amount of IP
> > and TCP header size added to the same amount of TCP payload).
> >
> > This should be good enough at this experimental
> > stage. If it raises problems, we will have to deal with them.
> >
> >
> > Bob
> >
> > PS. Strictly, congestion at the link layer
> > includes the size of link layer headers, and
> > congestion in a tunnel includes tunnel headers,
> > etc, etc. But for simplicity, from the
> > transport's viewpoint, I think it's reasonable to
> > use the size of the packet including the one IP
> > header that the transport can assume. This is a
> > bit like the transport layer checksum calculation
> > that includes an IP pseudo-header. But in this
> > case, the transport just adds a pseudo-size for the IP and TCP headers.
> >
> > At 00:15 07/10/2011, Mirja Kühlewind wrote:
> > >2. Which bytes of a packet do we take? The IP length incl header, the IP
> > >payload incl. TCP header or the actual payload?
> > >In TCP if a packet get lost (with SACK) we only know how many payload got
> > >lost. We do not know the number of packets/headers that were used to
> > > transmit this data. If we would loose one big packet and then retransmit
> > > a large number of small packets instead (which are all ConEx marked) that
> > > might give quite a different ConEx signal. On the other hand, what causes
> > > the congestion is the whole packet incl header(s). What is the right
> > > thing to do?
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design
>
>
>
>--
>-------------------------------------------------------------------
>Dipl.-Ing. Mirja Kühlewind
>Institute of Communication Networks and Computer Engineering (IKR)
>University of Stuttgart, Germany
>Pfaffenwaldring 47, D-70569 Stuttgart
>
>tel: [phone]
>email: [e-mail]
>web: www.ikr.uni-stuttgart.de
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design